Hologres:Métricas de monitoramento

Uso de CPU da instância (%)

A carga geral de CPU da instância.

Processos em segundo plano e tarefas de compactação consomem CPU mesmo sem consultas ativas; portanto, o uso em ociosidade é normal. O Hologres usa paralelismo multinúcleo, então uma única consulta pode elevar a CPU a 100% — isso indica utilização total dos recursos, não necessariamente um problema.

Quando investigar: Se o uso de CPU permanecer próximo de 100% por 3 horas ou acima de 90% por 12 horas, a instância estará sob carga pesada e a CPU provavelmente será o gargalo. Considere se:

• Importações grandes de dados offline (INSERT) estão em execução com volumes de dados crescentes.

• Consultas ou gravações de alto QPS estão consumindo todos os recursos de CPU.

• Cargas de trabalho híbridas combinam os cenários acima.

Se o uso elevado e sustentado de CPU for esperado, aumente a escala da instância.

FAQ sobre métricas de monitoramento.

Uso de CPU do nó Worker (%)

A carga de CPU em cada nó Worker. O número de nós Worker varia conforme o tipo de instância. Para mais informações, consulte Gerenciamento de instâncias.

Versão: V1.1+

• Se todos os nós Worker apresentarem uso sustentado de CPU próximo de 100%, a instância estará sob carga pesada. Otimize as consultas ou aumente a escala da instância.

• Se apenas alguns nós Worker apresentarem alto uso de CPU, haverá assimetria de recursos. Para causas comuns e solução de problemas, consulte FAQ sobre métricas de monitoramento.

Uso de CPU do cluster (%)

O uso de CPU de cada cluster no grupo de computação.

Versão: V4.0+. Apenas instâncias de grupo de computação.

Uso de memória da instância (%)

O consumo geral de memória da instância.

O Hologres reserva memória para metadados, índices e caches para acelerar consultas. Um uso em ociosidade de 30%–40% é típico. Se o uso subir em direção a 80%, a memória poderá se tornar um gargalo.

Use as métricas de distribuição de memória juntamente com o QPS e outros indicadores para identificar os maiores consumidores de memória. Guia de solução de problemas para falta de memória.

Uso de memória do nó Worker (%)

A carga de memória em cada nó Worker. O número de nós Worker varia conforme o tipo de instância. Para mais informações, consulte Gerenciamento de instâncias.

Versão: V1.1+

• Se todos os nós Worker apresentarem uso sustentado de memória próximo de 80%, a instância estará sob carga pesada. Otimize as consultas ou aumente a escala da instância.

• Se apenas alguns nós Worker apresentarem alto uso de memória, haverá assimetria de recursos. Para causas comuns e solução de problemas, consulte FAQ sobre métricas de monitoramento.

Uso detalhado de memória da instância (%)

Versão: V2.0+ (métricas de distribuição de memória disponíveis a partir da V2.0.15)

O Hologres divide a memória em seis categorias:

Solução de problemas: Alto uso de memória de Query ou eventos de falta de memória (OOM) geralmente indicam consultas complexas ou alta concorrência. Para orientações de otimização, consulte Otimizar desempenho de consultas.

Uso de memória de consulta QE (bytes)

A memória (em bytes) usada por consultas executadas pelos mecanismos HQE, SQE ou outros mecanismos XQE.

Versão: V2.0.44+ / V2.1.22+

Nos detalhamentos de memória, o uso de memória de Query excede o uso de memória de consulta QE porque Query inclui todos os tipos de mecanismo. Maior uso de memória de consulta QE indica consultas mais complexas que exigem mais memória.

Uso de memória de consulta QE (%)

A porcentagem de memória usada pelas consultas do mecanismo QE.

Versão: V2.0.44+ / V2.1.22+

O uso elevado pode levar a erros OOM. Otimize as consultas ou aumente a escala da instância.

Uso de memória do cluster (%)

O uso de memória de cada cluster no grupo de computação.

Versão: V4.0+. Apenas instâncias de grupo de computação.

QPS de consulta (contagem/s)

Média de instruções SQL executadas por segundo, incluindo SELECT, INSERT, UPDATE, DELETE, UTILITY e UNKNOWN.

Relação: Query QPS >= QE Query QPS + FixedQE Query QPS

O QPS total inclui todas as consultas (UNKNOWN, UTILITY, Engine Type={PG}); portanto, é igual ou superior à soma dos QPS do QE e FixedQE.

QPS de consulta QE (contagem/s)

Consultas por segundo executadas pelo mecanismo QE, incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

QPS de consulta FixedQE (contagem/s)

Consultas por segundo executadas pelo mecanismo FixedQE (caminho Fixed Plan, anteriormente SDK), incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

RPS de DML (contagem/s)

Média de registros de dados importados ou atualizados por segundo, incluindo INSERT, UPDATE e DELETE.

Relação: DML RPS = QE DML RPS + FixedQE DML RPS

RPS de DML do QE (contagem/s)

Registros de dados importados ou atualizados por segundo pelo mecanismo QE, incluindo INSERT, UPDATE e DELETE.

Versão: V2.2+

Cenários comuns de QE:

• Importação ou atualização em lote de tabelas externas do MaxCompute ou OSS

• Gravação ou atualização em lote usando COPY

• Importação em lote entre tabelas do Hologres

RPS de DML do FixedQE (contagem/s)

Registros de dados importados ou atualizados por segundo pelo mecanismo FixedQE (caminho Fixed Plan, anteriormente SDK), incluindo INSERT, UPDATE e DELETE.

Versão: V2.2+

Cenários comuns de FixedQE:

• Gravações em tempo real usando Flink

• Gravações usando Holo-Client

• Importações usando Spark

• Sincronização em tempo real de Binlog do MySQL para o Hologres

• Importações do DataHub

• Gravações offline usando Data Integration (DataX)

• Gravações usando SQL ou JDBC com INSERT INTO VALUES()

Latência de consulta (milissegundos)

Latência média de todas as consultas, incluindo SELECT, INSERT, UPDATE, DELETE, UTILITY e UNKNOWN.

Relação: Query Latency >= MAX(QE Query Latency, FixedQE Query Latency)

Latência de consulta QE (milissegundos)

Latência média das consultas executadas pelo mecanismo QE, incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

Para solucionar latência elevada de consulta QE, verifique as métricas de Duração da Fase de Otimização, Duração da Fase de Início da Consulta, Duração da Fase Get Next e QPS do QE.

Latência de consulta FixedQE (milissegundos)

Latência média das consultas executadas pelo mecanismo FixedQE, incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

Solução de problemas:

• Picos ocasionais: Podem indicar bloqueios HQE. Verifique se o Tempo de Espera de Bloqueio de Backend do FixedQE aumentou. Em caso afirmativo, use Obter insights de consulta para identificar as consultas causadoras do bloqueio.

• Latência persistentemente alta: Pode resultar de design de tabela subótimo ou interferência de consultas complexas. Consulte Problemas comuns e diagnósticos para Blink e Flink.

Duração da fase de otimização (milissegundos)

Tempo gasto na fase de Otimização, em que o otimizador analisa o SQL e gera um plano físico.

Versão: V2.0.44+ / V2.1.22+

Durações longas de Otimização sugerem consultas complexas. Se as consultas diferirem apenas nos parâmetros, use Prepared Statements para reduzir a sobrecarga de otimização. Para mais informações, consulte JDBC.

Duração da fase de início da consulta (milissegundos)

Tempo gasto na fase Start Query — inicialização antes da execução da consulta, incluindo bloqueios e alinhamento de versão de schema.

Versão: V2.0.44+ / V2.1.22+

Durações longas de Start Query frequentemente resultam de esperas de bloqueio ou alto uso de CPU. Use planos de execução para análise mais profunda.

Duração da fase Get Next (milissegundos)

Tempo do fim da fase Start Query até o retorno de todos os resultados, incluindo computação e entrega de resultados.

Versão: V2.0.44+ / V2.1.22+

Durações longas de Get Next frequentemente refletem computações complexas. Correlacione com o uso de memória do QE e o QPS do QE. Se não houver anomalias nessas métricas, o cliente pode estar simplesmente lento para consumir os resultados.

Latência P99 de consulta (milissegundos)

Latência do percentil 99 de todas as consultas, incluindo SELECT, INSERT, UPDATE, UTILITY e consultas de sistema.

Duração da consulta mais longa nesta instância (milissegundos)

Duração da consulta ativa em execução há mais tempo, abrangendo SELECT, INSERT, UPDATE, DELETE, UTILITY e UNKNOWN.

Versão: V1.1+

As consultas distribuem-se entre os nós Worker. Esta métrica reporta a consulta em execução há mais tempo em todos os Workers. Por exemplo, se os Workers executarem consultas de 10 minutos, 5 minutos e 30 segundos, o valor reportado será 10 minutos.

Combine esta métrica com consultas ativas ou logs de consultas lentas para diagnosticar consultas longas e resolver deadlocks.

As métricas são reportadas a cada minuto; portanto, a "duração atual de execução" começa ligeiramente após o início da consulta. Esta métrica é útil para detecção de anomalias, mas não fornece cronometragem precisa.

QPS de consultas com falha (milissegundos)

Média de instruções SQL com falha por segundo, incluindo SELECT, INSERT, UPDATE, DELETE, UTILITY e UNKNOWN.

Relação: Failed Query QPS >= QE Failed Query QPS + FixedQE Failed Query QPS

O QPS total de falhas inclui todas as consultas com falha (UNKNOWN, UTILITY, Engine Type={PG}); portanto, é igual ou superior à soma dos QPS de falhas do QE e FixedQE.

Use o tipo e a frequência de consultas com falha para encontrar as consultas problemáticas nos logs de consultas lentas e analise as causas raiz para melhorar a disponibilidade.

QPS de consultas com falha do QE (contagem/s)

Consultas com falha por segundo no mecanismo QE, incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

QPS de consultas com falha do FixedQE (contagem/s)

Consultas com falha por segundo no mecanismo FixedQE, incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

Tempo máximo de espera de bloqueio FE (milissegundos)

O Hologres possui múltiplos nós FE que analisam, despacham e roteiam instruções SQL. Quando múltiplas conexões no mesmo FE realizam operações DDL na mesma tabela (como CREATE ou DROP), ocorrem bloqueios FE. Esta métrica mostra o tempo de espera de bloqueio DDL por FE.

Versão: V2.2+

Se o tempo de espera de bloqueio FE exceder 5 minutos e o Atraso de Replay do FE também tiver picos, uma operação DDL poderá estar travada. Use Gerenciar consultas para encontrar e encerrar consultas longas.

Tempo de espera de bloqueio de backend do FixedQE (milissegundos)

Consultas INSERT, DELETE ou UPDATE usando HQE adquirem bloqueios de tabela, enquanto consultas FixedPlan adquirem bloqueios de linha. Esta métrica aumenta quando consultas FixedPlan aguardam bloqueios de linha enquanto consultas HQE mantêm bloqueios de tabela na mesma tabela.

Versão: V2.2+

Se este valor for alto, verifique os logs de consultas lentas para consultas FixedQE lentas e use Obter insights de consulta para identificar as consultas HQE causadoras do bloqueio.

Tempo total de espera de bloqueio de backend da instância (milissegundos)

O tempo total de espera de bloqueio para consultas INSERT, DELETE ou UPDATE na instância, incluindo tanto as esperas de bloqueio do FixedQE quanto do HQE.

Versão: V2.2+

Se este valor for alto, verifique os logs de consultas lentas para consultas INSERT, DELETE ou UPDATE lentas e use Obter insights de consulta para identificar as consultas HQE causadoras do bloqueio.

Conexões do Gateway (contagem)

Total de conexões na camada de Gateway da instância, refletindo a carga geral de conexões na camada de acesso.

• Conexões do Gateway = conexões FE + WAL senders FE + Fixed FE não Binlog + Fixed FE Binlog.

• Se as conexões do Gateway permanecerem próximas do limite da instância por um período prolongado, os recursos de conexão estarão se aproximando da saturação. Limpe conexões ociosas ou aumente a escala para obter mais capacidade de conexão.

Uso máximo de conexão do Gateway (%)

A taxa máxima de uso de conexões do Gateway, refletindo a pressão de pico no pool de conexões da camada de acesso. Quando o uso se aproxima consistentemente de 100%, novas conexões podem falhar. Investigue em conjunto com a métrica de Conexões do Gateway e considere aumentar a escala.

Conexões FE (contagem)

Conexões em nós FE (Frontend), refletindo a carga de conexão na camada de análise e roteamento de SQL. O Hologres define limites padrão de conexão FE com base nas especificações da instância. Para mais informações, consulte Gerenciamento de instâncias. Inclui conexões ativas, ociosas e ociosas em transação. Use Gerenciar consultas para visualizar o uso atual de conexões e encerrar conexões ociosas quando os recursos estiverem baixos.

Conexões FE por banco de dados (contagem)

Conexões FE divididas por banco de dados, para identificar quais bancos de dados consomem mais conexões.

Conexões FE por nó FE (contagem)

Conexões FE divididas por nó FE, para avaliar se a carga de conexão está balanceada entre os nós.

• Limite padrão de conexão por nó FE: 128. Para limites totais, consulte Gerenciamento de instâncias.

• Se as conexões em qualquer nó se aproximarem do limite, revise as conexões ociosas versus ativas. Use Gerenciar conexões para limpar conexões ociosas ou aumentar a escala.

• Se a carga de conexão estiver desigual entre os nós, use Gerenciar conexões para identificar e limpar conexões ociosas.

Uso máximo de conexão FE (%)

A taxa máxima de uso de conexão FE: Max(frontend_connection_used_rate). Use isto para detectar quando qualquer nó FE estiver se aproximando de seu limite de conexão. Os nós FE usam balanceamento de carga round-robin. Use Gerenciar consultas para visualizar detalhes de uso e encerrar conexões ociosas quando necessário.

Contagem de WAL Sender do FE por nó FE (contagem)

WAL senders por nó FE. Ao consumir Binlog via JDBC, cada shard de cada tabela usa uma conexão WAL sender. As conexões WAL sender são independentes das conexões regulares e possuem seu próprio limite. Use esta métrica para monitorar a utilização de WAL sender por nó FE.

Uso máximo de WAL Sender (%)

A taxa máxima de uso de WAL sender, refletindo a pressão máxima nas conexões relacionadas ao Binlog. Quando o uso se aproxima do limite, o consumo de Binlog pode ser afetado. Investigue e aumente a escala conforme necessário.

Conexões Fixed FE (não Binlog) (contagem)

Conexões não Binlog em nós Fixed FE, refletindo a carga de conexão no caminho de execução do Fixed Plan.

Conexões Binlog do Fixed FE (contagem)

Conexões Binlog em nós Fixed FE, refletindo a carga de conexão relacionada ao Binlog no caminho de execução do Fixed Plan.

Contagem de consultas na fila (contagem)

O número de solicitações de consulta aguardando execução.

Versão: V3.0+

QPS de entrada na fila de consultas (contagem/s)

Consultas enviadas para a fila do sistema por segundo. Use isto para medir a carga do sistema e a frequência de consultas.

Versão: V3.0+

QPS de consultas transicionadas de enfileiradas para em execução (contagem/s)

Consultas passando do estado de espera para o estado de execução por segundo.

Versão: V3.0+

QPS por estado para consultas que iniciaram execução (contagem/s)

Contagem por segundo de consultas na fila de consultas, agrupadas por estado:

• kReadyToRun — qualificada para execução

• kQueueTimeout — falhou devido a timeout na fila

• kCanceled — falhou devido a cancelamento

• kExceedConcurrencyLimit — falhou devido ao limite de concorrência

Versão: V3.0+

Tempo médio de espera na fila de consultas (milissegundos)

O tempo médio da entrada na fila até o início do processamento. Isso não inclui o tempo real de execução da consulta.

Versão: V3.0+

Concorrência máxima de limite automático de taxa da fila de consultas (contagem)

A concorrência máxima para filas de consultas com limite automático de taxa.

Versão: V3.1+. Apenas instâncias de grupo de computação.

Throughput de leitura de I/O padrão (bytes/s)

Throughput de leitura para dados do armazenamento Standard.

Throughput de gravação de I/O padrão (bytes/s)

Throughput de gravação para dados do armazenamento Standard.

Throughput de leitura de I/O de baixa frequência (bytes/s)

Throughput de leitura para dados do armazenamento IA.

Throughput de gravação para I/O de baixa frequência (bytes/s)

Throughput de gravação para dados do armazenamento IA.

Capacidade usada do armazenamento Standard (bytes)

A capacidade usada no armazenamento Standard. Aumente a escala do armazenamento se o uso exceder a capacidade comprada.

Uso do armazenamento Standard (%)

A porcentagem de uso da capacidade do armazenamento Standard. Aumente a escala do armazenamento se o uso exceder a capacidade comprada.

Capacidade usada do armazenamento IA (bytes)

A capacidade usada no armazenamento IA. Aumente a escala do armazenamento se o uso exceder a capacidade comprada.

Uso do armazenamento IA (%)

A porcentagem de uso da capacidade do armazenamento IA. Aumente a escala do armazenamento se o uso exceder a capacidade comprada.

Uso de armazenamento da Lixeira (bytes)

Versão: V3.1+

O Hologres oferece suporte a uma lixeira de tabelas a partir da V3.1. Tabelas excluídas com DROP permanecem na lixeira por um período de retenção, permitindo a recuperação de tabelas excluídas acidentalmente. Essas tabelas ainda consomem armazenamento da instância.

Monitore o uso da lixeira por banco de dados. Se exclusões frequentes de tabelas causarem alto uso da lixeira, configure as tabelas para ignorar a lixeira upon deletion.

Atraso de replay do FE (milissegundos)

Versão: V2.2+

O Hologres possui múltiplos nós FE. Para operações DDL, o Hologres executa a operação em um FE e a replica nos outros. Atrasos de replay de milissegundos ou segundos são normais.

Se o atraso de replay de um FE exceder vários minutos, muitas operações DDL poderão estar sobrecarregando o processo de replay. Se o atraso continuar aumentando, uma consulta poderá estar travada. Use hg_stat_activity para encontrar e encerrar consultas longas.

Atraso de sincronização de múltiplas réplicas de shard (milissegundos)

O atraso de sincronização entre réplicas de shard após a ativação da Replicação.

O atraso típico de réplica de shard é em milissegundos. Gravações pesadas de dados, atualizações ou operações DDL frequentes podem aumentar o atraso de sincronização.

Atraso de sincronização primário-follower (milissegundos)

O atraso quando uma instância follower lê dados da instância primária. Esta métrica aparece apenas para instâncias follower, não para instâncias primárias.

• Os dados aparecem apenas depois que uma instância follower é vinculada a uma instância primária (0 ms inicialmente). O atraso de sincronização flutua quando a instância primária recebe gravações.

• O atraso normal de sincronização é em milissegundos. Jitter ocasional de operações DDL primárias pode ser ignorado com segurança. Atraso persistentemente alto de mais de alguns segundos pode indicar alta carga da instância ou falta de recursos — verifique o uso de CPU e memória e aumente a escala se necessário.

• O atraso de sincronização pode ter picos de vários minutos durante reinicializações ou atualizações e depois se recupera automaticamente.

Atraso de sincronização de arquivos entre instâncias (milissegundos)

O atraso de sincronização de arquivos entre instâncias de recuperação de desastres. Esta métrica aparece apenas em instâncias follower (followers somente leitura).

Tabelas sem estatísticas por banco de dados (contagem)

O número de tabelas sem estatísticas em cada banco de dados.

Versão: V2.2+

Para Hologres V2.0 e posterior, o Auto Analyze é executado por padrão. Após a criação de tabelas ou gravações/atualizações em massa, as estatísticas podem ficar temporariamente atrasadas — observe por um curto período primeiro.

Se um banco de dados consistentemente carecer de estatísticas por horas ou dias, o Auto Analyze pode não ter sido acionado. Use a view HG_STATS_MISSING para listar as tabelas afetadas e execute manualmente o ANALYZE. Para mais informações, consulte ANALYZE e AUTO ANALYZE.

Duração da consulta mais longa do Serverless Computing (milissegundos)

A duração da consulta em execução há mais tempo no Serverless Computing. O Serverless Computing executa consultas específicas em um pool de recursos dedicado, isolado da instância principal.

Versão: V2.1+

Use hg_stat_activity para inspecionar o status das consultas do Serverless Computing.

Contagem de consultas na fila do Serverless Computing (contagem)

O número de consultas enfileiradas no pool de recursos do Serverless Computing.

Versão: V2.2+

Uso da cota de recursos do Serverless Computing (%)

A proporção entre os recursos reais do Serverless Computing usados e o máximo de recursos alocáveis.

Versão: V2.2+

Taxa de consumo de Binlog (contagem/s)

O número de entradas de Binlog consumidas por segundo. O Hologres oferece suporte à assinatura de Binlog do Hologres para camadas de dados em tempo real e encaminhamento acelerado de dados.

Versão: V2.2+

Taxa de consumo de Binlog (bytes/s)

Os bytes consumidos do Binlog por segundo. Campos maiores ou volumes de dados mais altos aumentam a contagem de bytes.

Versão: V2.2+

Contagem de WAL Sender por FE (contagem)

O número de WAL senders usados por nó FE. Cada shard de cada tabela consome uma conexão WAL sender ao consumir Binlog usando JDBC. As conexões WAL sender são independentes das conexões regulares e possuem um limite padrão.

Versão: V2.2+

Taxa de uso de WAL Sender do FE com maior uso (%)

A utilização máxima de WAL sender em todos os nós FE.

Versão: V2.2+

Se o uso de WAL sender atingir o limite, consulte Consumir Binlog do Hologres via JDBC para solução de problemas.

Contagem de núcleos elásticos para grupos de computação

Núcleos adicionados por dimensionamento baseado em tempo no grupo de computação. Elasticidade baseada em tempo (Beta).

Versão: V2.2.21+. Apenas instâncias de grupo de computação.

Contagem de núcleos autoelásticos do grupo de computação (contagem)

Núcleos adicionados por Auto Scaling no grupo de computação. Multicluster e autoelasticidade (Beta).

Versão: V4.0+. Apenas instâncias de grupo de computação.

Uso de CPU do Gateway (%)

O uso de CPU de cada Gateway na instância.

Versão: V2.0+. Apenas instâncias de grupo de computação.

Os Gateways usam encaminhamento de tráfego round-robin, então o uso de CPU ocorre mesmo sem novas conexões. A partir da V2.2.22, os Gateways lançam mais threads de worker por padrão para melhorar o manuseio de conexões, o que aumenta o uso básico de CPU.

Uso de memória do Gateway (%)

O uso de memória de cada Gateway na instância.

Versão: V2.0+. Apenas instâncias de grupo de computação.

Novas solicitações de conexão do Gateway por segundo (contagem/s)

O número máximo de novas conexões que o sistema pode aceitar e estabelecer com sucesso por segundo.

Versão: V2.1.12+. Apenas instâncias de grupo de computação.

Um único Gateway lida com aproximadamente 100 novas conexões por segundo. Se as solicitações de nova conexão se aproximarem de 100 x Gateway count, os Gateways serão o gargalo. Configure um pool de conexões ou aumente o número de Gateways.

Taxa de tráfego de entrada do Gateway (B/s)

O volume de dados entrando pelo Gateway por segundo.

Versão: V2.1+. Apenas instâncias de grupo de computação.

Se o tráfego de entrada se aproximar de 200 MiB/s x Gateway count, a capacidade de rede do Gateway será o gargalo. Aumente o número de Gateways.

Taxa de tráfego de saída do Gateway (B/s)

O volume de dados enviados pelo Gateway por segundo.

Versão: V2.1+. Apenas instâncias de grupo de computação.

Se o tráfego de saída se aproximar de 200 MiB/s x Gateway count, a capacidade de rede do Gateway será o gargalo. Aumente o número de Gateways.