Hologres:Monitoring metrics

Instance CPU Usage (%)

A carga geral de CPU da instância.

Processos em segundo plano e tarefas de compactação consomem CPU mesmo na ausência de consultas ativas, portanto um uso ocioso é normal. O Hologres utiliza paralelismo multi-core, de modo que uma única consulta pode levar o CPU a 100% — isso indica utilização plena dos recursos, não necessariamente um problema.

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

• Importações de dados offline de grande volume (INSERT) estão em execução com volumes 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 alto uso de CPU for esperado de forma contínua, escale verticalmente a instância.

FAQ for monitoring metrics.

Worker Node CPU Usage (%)

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 Instance management.

Versão: V1.1+

• Se todos os nós Worker apresentarem uso de CPU próximo a 100% de forma contínua, a instância está sob carga elevada. Otimize as consultas ou escale verticalmente a instância.

• Se apenas alguns nós Worker apresentarem alto uso de CPU, há um desequilíbrio de recursos. Para causas comuns e procedimentos de solução de problemas, consulte FAQ for monitoring metrics.

Cluster CPU Usage (%)

O uso de CPU de cada cluster no compute group.

Versão: V4.0+. Exclusivo para instâncias do tipo compute group.

Uso de Memória da Instância (%)

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

O Hologres reserva memória para metadados, índices e caches a fim de acelerar consultas. Um uso ocioso de 30%–40% é típico. Se o uso se aproximar de 80%, a memória pode se tornar um gargalo.

Combine as métricas de distribuição de memória com QPS e outros indicadores para identificar os maiores consumidores de memória. Troubleshooting guide for out-of-memory issues.

Uso de Memória do Worker Node (%)

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 Instance management.

Versão: V1.1+

• Se todos os nós Worker apresentarem uso de memória próximo a 80% de forma contínua, a instância está com carga elevada. Otimize as consultas ou faça upgrade da instância.

• Se apenas alguns nós Worker apresentarem uso elevado de memória, há um desequilíbrio de recursos. Para causas comuns e resolução de problemas, consulte FAQ for monitoring metrics.

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:

Resolução de problemas: Uso elevado de memória em Query ou eventos de out-of-memory (OOM) geralmente indicam consultas complexas ou alta concorrência. Para orientações de otimização, consulte Optimize query performance.

Uso de Memória QE Query (bytes)

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

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

Nos detalhamentos de memória, o uso de memória em Query supera o uso de memória em QE Query porque Query engloba todos os tipos de engine. Valores mais altos de uso de memória em QE Query indicam consultas mais complexas, que demandam mais memória.

Uso de Memória QE Query (%)

O percentual de memória utilizado pelas consultas do engine QE.

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

Uso elevado pode levar a erros de OOM. Otimize as consultas ou faça upgrade 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+. Exclusivo para instâncias com grupo de computação.

QPS de Consultas (count/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 de QE e FixedQE.

QPS de QE Query (count/s)

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

Versão: V2.2+

QPS de FixedQE Query (count/s)

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

Versão: V2.2+

DML RPS (count/s)

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

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

QE DML RPS (count/s)

Registros importados ou atualizados por segundo pelo engine QE, incluindo INSERT, UPDATE e DELETE.

Versão: V2.2+

Cenários comuns de QE:

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

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

• Importação em lote entre tabelas Hologres

FixedQE DML RPS (count/s)

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

Versão: V2.2+

Cenários comuns de FixedQE:

• Real-time writes using Flink

• Writes using Holo-Client

• Imports using Spark

• Real-time synchronization of MySQL Binlog to Hologres

• Imports from DataHub

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

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

Latência de Consultas (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 QE Query (milissegundos)

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

Versão: V2.2+

Para diagnosticar latência elevada em QE Query, verifique as métricas Optimization Phase Duration, Start Query Phase Duration, Get Next Phase Duration e QE QPS.

Latência de FixedQE Query (milissegundos)

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

Versão: V2.2+

Resolução de problemas:

• Picos ocasionais: Podem indicar locks de HQE. Verifique se o FixedQE Backend Lock Wait Time aumentou. Em caso positivo, use Get query insights para identificar as consultas que estão causando o lock.

• Latência persistentemente alta: Pode resultar de um design de tabela inadequado ou interferência de consultas complexas. Consulte Common issues and diagnostics for Blink and 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 indicam consultas complexas. Se as consultas diferem apenas nos parâmetros, use Prepared Statements para reduzir a sobrecarga de otimização. Para mais informações, consulte JDBC.

Duração da Fase Start Query (milissegundos)

Tempo gasto na fase Start Query — inicialização anterior à execução da consulta, incluindo lock e alinhamento de versão do esquema.

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

Durações longas em Start Query geralmente resultam de esperas por lock ou uso elevado de CPU. Use execution plans para uma análise mais detalhada.

Duração da Fase Get Next (milissegundos)

Tempo decorrido entre o fim da fase Start Query e o retorno de todos os resultados, incluindo processamento e entrega dos resultados.

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

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

Latência P99 de Consultas (milissegundos)

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

Duração da Consulta Mais Longa em Execução na Instância (milissegundos)

Duração da consulta ativa com maior tempo de execução, abrangendo SELECT, INSERT, UPDATE, DELETE, UTILITY e UNKNOWN.

Versão: V1.1+

As consultas são distribuídas entre os nós Worker. Essa métrica reporta a consulta de maior duração entre todos os Workers. Por exemplo, se os Workers executam consultas de 10 minutos, 5 minutos e 30 segundos, o valor reportado é 10 minutos.

Combine esta métrica com active queries ou slow query logs para diagnosticar consultas de longa duração e resolver deadlocks.

As métricas são reportadas a cada minuto, portanto a "duração atual em execução" começa ligeiramente após o início da consulta. Essa métrica é útil para detecção de anomalias, mas não fornece temporização 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 falha de QE e FixedQE.

Use o tipo e a frequência das consultas com falha para localizar as consultas problemáticas em slow query logs e, em seguida, analise as causas raiz para melhorar a disponibilidade.

QPS de QE Failed Query (count/s)

Consultas com falha por segundo pelo engine QE, incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

QPS de FixedQE Failed Query (count/s)

Consultas com falha por segundo pelo engine FixedQE, incluindo SELECT, INSERT, UPDATE e DELETE.

Versão: V2.2+

Tempo Máximo de Espera por Lock de FE (milissegundos)

O Hologres possui múltiplos nós FE responsáveis por analisar, despachar e rotear instruções SQL. Quando múltiplas conexões no mesmo FE executam operações DDL sobre a mesma tabela (como CREATE ou DROP), ocorrem locks de FE. Essa métrica exibe o tempo de espera pelo lock de DDL por FE.

Versão: V2.2+

Se o tempo de espera pelo lock de FE ultrapassar 5 minutos e o FE Replay Delay também apresentar pico, uma operação DDL pode estar travada. Use Manage queries para localizar e encerrar consultas de longa duração.

Tempo de Espera por Lock de FixedQE Backend (milissegundos)

Consultas INSERT, DELETE ou UPDATE executadas pelo HQE adquirem locks de tabela, enquanto consultas FixedPlan adquirem locks de linha. Essa métrica aumenta quando consultas FixedPlan aguardam locks de linha enquanto consultas HQE mantêm locks de tabela na mesma tabela.

Versão: V2.2+

Se esse valor estiver alto, verifique os logs de consultas lentas em busca de consultas FixedQE lentas e use Get query insights para identificar as consultas HQE que estão causando o lock.

Tempo Total de Espera por Lock de Backend na Instância (milissegundos)

O tempo total de espera por lock para consultas INSERT, DELETE ou UPDATE na instância, incluindo os locks de FixedQE e HQE.

Versão: V2.2+

Se esse valor estiver alto, verifique os logs de consultas lentas em busca de consultas INSERT, DELETE ou UPDATE lentas e use Get query insights para identificar as consultas HQE que estão causando o lock.

Conexões de Gateway (count)

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

• Conexões de Gateway = conexões FE + FE WAL senders + Fixed FE non-Binlog + Fixed FE Binlog.

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

Uso Máximo de Conexões de Gateway (%)

A taxa de pico de uso de conexões de Gateway, refletindo a pressão máxima sobre o 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 Gateway Connections e considere fazer upgrade.

Conexões FE (count)

Conexões nos nós FE (Frontend), refletindo a carga de conexões na camada de análise e roteamento de SQL. O Hologres define limites padrão de conexões FE com base nas especificações da instância. Para mais informações, consulte Instance management. Inclui conexões ativas, ociosas e idle-in-transaction. Use Manage queries para visualizar o uso atual de conexões e encerrar conexões ociosas quando os recursos estiverem escassos.

Conexões FE por Banco de Dados (count)

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

Conexões FE por Nó FE (count)

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

• Limite padrão de conexões por nó FE: 128. Para limites totais, consulte Instance management.

• Se as conexões em algum nó se aproximarem do limite, revise a proporção entre conexões ociosas e ativas. Use Manage connections para limpar conexões ociosas ou faça upgrade.

• Se a carga de conexões estiver desbalanceada entre os nós, use Manage connections para identificar e limpar conexões ociosas.

Uso Máximo de Conexões FE (%)

A taxa de pico de uso de conexões FE: Max(frontend_connection_used_rate). Use esta métrica para detectar quando algum nó FE está se aproximando do seu limite de conexões. Os nós FE utilizam balanceamento de carga round-robin. Use Manage queries para visualizar detalhes de uso e encerrar conexões ociosas quando necessário.

Contagem de WAL Senders de FE por Nó FE (count)

WAL senders por nó FE. Ao consumir Binlog via JDBC, cada shard de cada tabela utiliza 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 senders por nó FE.

Uso Máximo de WAL Sender (%)

A taxa de pico de uso de WAL senders, refletindo a pressão máxima sobre as conexões relacionadas a Binlog. Quando o uso se aproxima do limite, o consumo de Binlog pode ser afetado. Investigue e faça upgrade conforme necessário.

Conexões Fixed FE (não-Binlog) (count)

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

Conexões Fixed FE Binlog (count)

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

Contagem de Consultas na Fila (count)

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

Versão: V3.0+

QPS de Entrada na Fila de Consultas (count/s)

Consultas submetidas à fila do sistema por segundo. Use esta métrica para avaliar a carga do sistema e a frequência de consultas.

Versão: V3.0+

QPS de Consultas Transicionadas de Aguardando para Em Execução (count/s)

Consultas que passam do estado de espera para o estado em execução por segundo.

Versão: V3.0+

QPS por Status para Consultas que Iniciaram Execução (count/s)

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

• kReadyToRun — apta para execução

• kQueueTimeout — falhou por timeout na fila

• kCanceled — falhou por cancelamento

• kExceedConcurrencyLimit — falhou por limite de concorrência

Versão: V3.0+

Tempo Médio de Espera na Fila de Consultas (milissegundos)

O tempo médio desde a entrada na fila até o início do processamento. Não inclui o tempo de execução efetiva da consulta.

Versão: V3.0+

Concorrência Máxima com Auto-Rate-Limit na Fila de Consultas (count)

A concorrência máxima para filas de consultas com auto-rate-limit.

Versão: V3.1+. Exclusivo para instâncias com grupo de computação.

Throughput de Leitura I/O Standard (bytes/s)

Throughput de leitura para dados de armazenamento Standard.

Throughput de Gravação I/O Standard (bytes/s)

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

Throughput de Leitura I/O de Baixa Frequência (bytes/s)

Throughput de leitura para dados de armazenamento IA.

Throughput de Gravação I/O de Baixa Frequência (bytes/s)

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

Capacidade Utilizada de Armazenamento Standard (bytes)

A capacidade utilizada no armazenamento Standard. Faça upgrade do armazenamento se o uso ultrapassar a capacidade adquirida.

Uso de Armazenamento Standard (%)

O percentual de uso da capacidade de armazenamento Standard. Faça upgrade do armazenamento se o uso ultrapassar a capacidade adquirida.

Capacidade Utilizada de Armazenamento IA (bytes)

A capacidade utilizada no armazenamento IA. Faça upgrade do armazenamento se o uso ultrapassar a capacidade adquirida.

Uso de Armazenamento IA (%)

O percentual de uso da capacidade de armazenamento IA. Faça upgrade do armazenamento se o uso ultrapassar a capacidade adquirida.

Uso de Armazenamento da Lixeira (bytes)

Versão: V3.1+

O Hologres oferece suporte a uma table recycle bin 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 uso elevado da lixeira, configure as tabelas para ignorar a lixeira ao serem excluídas.

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 demais. Atrasos de replay na ordem de milissegundos ou segundos são normais.

Se o atraso de replay de um FE ultrapassar alguns minutos, um volume excessivo de operações DDL pode estar sobrecarregando o processo de replay. Se o atraso continuar aumentando, uma consulta pode estar travada. Use hg_stat_activity para localizar e encerrar consultas de longa duração.

Atraso de Sincronização entre Réplicas de Shard (milissegundos)

O atraso de sincronização entre réplicas de Shard após a ativação de Replication.

O atraso típico de réplica de Shard é da ordem de milissegundos. Gravações intensas de dados, atualizações frequentes ou operações DDL frequentes podem aumentar o atraso de sincronização.

Atraso de Sincronização Primário-Seguidor (milissegundos)

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

• Os dados aparecem somente após uma instância seguidora ser vinculada a uma instância primária (inicialmente 0 ms). O atraso de sincronização oscila quando a instância primária recebe gravações.

• O atraso de sincronização normal é da ordem de milissegundos. Oscilações ocasionais causadas por operações DDL na instância primária podem ser ignoradas com segurança. Um atraso persistentemente elevado de mais de alguns segundos pode indicar carga elevada ou escassez de recursos na instância — verifique o uso de CPU e memória e faça upgrade se necessário.

• O atraso de sincronização pode aumentar para alguns minutos durante reinicializações ou upgrades e se recupera automaticamente em seguida.

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. Essa métrica aparece apenas em instâncias seguidoras (seguidores somente leitura).

Tabelas sem Estatísticas por Banco de Dados (count)

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

Versão: V2.2+

No Hologres V2.0 e posteriores, 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 defasadas — observe por um curto período antes de agir.

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

Duração da Consulta Mais Longa em Execução no Serverless Computing (milissegundos)

A duração da consulta com maior tempo de execução 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 (count)

O número de consultas na fila do pool de recursos do Serverless Computing.

Versão: V2.2+

Uso da Cota de Recursos do Serverless Computing (%)

A proporção entre os recursos de Serverless Computing efetivamente utilizados e o máximo de recursos alocáveis.

Versão: V2.2+

Taxa de Consumo de Binlog (count/s)

O número de entradas de Binlog consumidas por segundo. O Hologres oferece suporte a subscribing to Hologres Binlog 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 elevados aumentam a contagem de bytes.

Versão: V2.2+

Contagem de WAL Senders por FE (count)

O número de WAL senders utilizados por nó FE. Cada shard de cada tabela consome uma conexão WAL sender ao consumir Binlog via 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 Utilização (%)

O pico de utilização de WAL senders entre todos os nós FE.

Versão: V2.2+

Se o uso de WAL senders atingir o limite, consulte Consume Hologres Binlog via JDBC para resolução de problemas.

Contagem de Cores Elásticos para Grupos de Computação

Cores adicionados por dimensionamento baseado em horário no grupo de computação. Time-based elasticity (Beta).

Versão: V2.2.21+. Exclusivo para instâncias com grupo de computação.

Contagem de Cores com Auto-Elastic no Grupo de Computação (count)

Cores adicionados por auto-scaling no grupo de computação. Multi-cluster and auto-elasticity (Beta).

Versão: V4.0+. Exclusivo para instâncias com grupo de computação.

Uso de CPU do Gateway (%)

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

Versão: V2.0+. Exclusivo para instâncias com grupo de computação.

Os Gateways utilizam encaminhamento de tráfego round-robin, portanto o uso de CPU ocorre mesmo sem novas conexões. A partir da V2.2.22, os Gateways iniciam mais threads de trabalho por padrão para melhorar o tratamento de conexões, o que aumenta o uso de CPU na linha de base.

Uso de Memória do Gateway (%)

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

Versão: V2.0+. Exclusivo para instâncias com grupo de computação.

Novas Requisições de Conexão por Segundo no Gateway (count/s)

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

Versão: V2.1.12+. Exclusivo para instâncias com grupo de computação.

Um único Gateway processa aproximadamente 100 novas conexões por segundo. Se as requisições de novas conexões se aproximarem de 100 x Gateway count, os Gateways sã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 que entra pelo Gateway por segundo.

Versão: V2.1+. Exclusivo para instâncias com 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 é o gargalo. Aumente o número de Gateways.

Taxa de Tráfego de Saída do Gateway (B/s)

O volume de dados enviado pelo Gateway por segundo.

Versão: V2.1+. Exclusivo para instâncias com 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 é o gargalo. Aumente o número de Gateways.