Lindorm:Monitoramento e alertas

Limiar de alerta

Use CPU idle rate(%) como métrica principal de alerta, em vez da utilização de CPU. O impacto da alta utilização de CPU varia conforme a carga de trabalho:

• Cargas de trabalho online (sensíveis a latência) podem sofrer degradação quando a utilização de CPU excede 40%.

• Cargas de trabalho em lote offline podem tolerar 100% de utilização de CPU sem problemas.

Defina o limiar de alerta com base no ponto em que sua carga de trabalho específica começa a apresentar latência, em vez de usar um número fixo.

Se os recursos de CPU forem insuficientes, gerencie o espaço de armazenamento. Consulte também modifique as configurações de uma instância.

Diagnóstico de gargalos de CPU versus disco

Duas métricas ajudam a distinguir pressão de CPU de pressão de disco:

• CPU WIO usage(%): porcentagem de tempo em que a CPU aguarda I/O. Um valor alto indica gargalo de leitura/gravação de disco.

• Average load per minute(load1): reflete o uso combinado de CPU e disco.

Analise essas métricas em conjunto. Um valor de carga aceitável equivale aproximadamente ao número de núcleos de CPU. Em uma máquina de 8 núcleos, por exemplo, uma carga acima de 8 significa que as tarefas estão enfileirando e a máquina opera em estado subótimo. Se a utilização de CPU estiver baixa, mas a carga alta, o gargalo é o I/O de disco.

Quando a carga de CPU ou a utilização de WIO estiver muito alta, escale verticalmente ou atualize a instância.

Limites de limitação

Os limites de largura de banda de rede do ECS variam conforme o tipo de instância. Consulte Visão geral das famílias de instâncias. Para limites de disco, consulte Desempenho de armazenamento em bloco.

Associe seu tipo de armazenamento Lindorm aos parâmetros de desempenho corretos do ECS:

Para dúvidas sobre limites de rede e disco, entre em contato com o suporte técnico do Lindorm (ID do DingTalk: s0s3eg3).

Uso de memória

Métrica: LindormTable compute node memory usage ratio(%)

Representa a proporção de memória heap em uso pelo LindormTable. O tamanho do heap flutua naturalmente, e picos curtos são gerenciados pela coleta de lixo (GC). A preocupação real é o uso elevado sustentado.

Regra de alerta: dispare quando essa proporção exceder 85%–90% por 30–60 minutos consecutivos.

Se o uso do heap permanecer consistentemente alto, atualize as especificações do nó do LindormTable para aumentar a memória. Consulte Alterar a especificação do mecanismo de uma instância.

Contagem de shards

Métrica: Number of regions of RS (unit)

O LindormTable divide tabelas em shards de dados (Regiões) e os distribui entre os nós. Cada shard consome memória de metadados; portanto, um número excessivo causa pressão na memória.

Limites de referência por memória do nó:

Esses valores são pontos de partida. Para uma avaliação mais precisa, verifique a proporção real de memória: Used memory / Total memory do nó de computação do LindormTable. Se a contagem de shards for muito alta, reduza-a diminuindo o número de tabelas ou as pré-partições ao criar tabelas.

Fila de solicitações

Métrica: HandlerQueue Length (unit)

Essa métrica mostra quantas solicitações aguardam na fila por um thread do servidor. Qualquer valor acima de 0 significa que o servidor não processa solicitações com rapidez suficiente.

Uma HandlerQueue persistentemente diferente de zero indica recursos de CPU insuficientes. Atualize a configuração da instância para adicionar capacidade de CPU.

Fila de compactação

Métrica: Compaction Queue Length (units)

A compactação consolida arquivos de dados dentro dos shards. Cargas de trabalho com muitas gravações geram naturalmente mais tarefas de compactação, que podem acumular na fila.

Nem todo enfileiramento é um problema. Cargas de trabalho com picos previsíveis (movimentadas durante o dia e calmas à noite) podem acumular tarefas de compactação no horário de pico e zerar a fila durante a noite. Esse comportamento é saudável. Da mesma forma, uma fila estável em um valor fixo indica estado estacionário e não requer atenção.

Quando agir: se a fila crescer continuamente sem tendência de queda, a instância não tem recursos suficientes. Adicione nós ou atualize a configuração de CPU.

Acúmulos de compactação de curto prazo não afetam leituras ou gravações. Já os de longo prazo aumentam o tempo de resposta (RT) de leitura devido à maior quantidade de arquivos de dados por shard. Eventualmente, um shard pode acumular arquivos suficientes para acionar contrapressão de gravação, resultando em aumento do RT de gravação ou até mesmo timeouts.

Arquivos por shard

Duas métricas relacionadas rastreiam a acumulação de arquivos nos shards:

• Average number of files in Region: valores mais altos aumentam o RT de leitura. O excesso de arquivos também eleva a pressão na memória e pode acionar Full GC ou OOM.

• Maximum number of files in Region: ao exceder o limite, a instância aplica contrapressão de gravação, causando timeouts. Consulte Limites em solicitações de dados.

Monitore essas métricas juntamente com Compaction Queue Length, pois altas contagens de arquivos geralmente seguem acúmulos sustentados de compactação.

Operações Get

Uma consulta pontual usa uma chave primária completa para recuperar uma única linha. O BatchGet executa serialmente em um único servidor. Independentemente de quantas linhas busque, conta como uma única chamada de consulta pontual. Isso significa que Get Average RT reflete a duração do BatchGet, superior ao RT de Get de linha única quando operações BatchGet são frequentes.

Operações Scan

O Lindorm divide grandes scans de intervalo em sub-scans e retorna resultados em streaming. Scan requests (pieces/second) conta sub-scans por segundo, não o número de solicitações originais do cliente. O tempo total de um scan completo corresponde à soma das durações de todos os seus sub-scans.

Métricas agregadas de leitura

Essas métricas cobrem operações Get e Scan e medem o throughput no nível da linha. Como um único Get ou Scan pode retornar várias linhas, elas refletem o throughput real de leitura com mais precisão do que apenas a contagem de operações.

Throughput de gravação

Métrica: Write traffic (unidade: KB/s)

Representa o volume real de dados gravados no armazenamento subjacente do LindormTable. Como as colunas de tabelas largas são convertidas em pares chave-valor durante o armazenamento, o volume armazenado é maior do que os dados efetivamente gravados pelo cliente.

Alto throughput de gravação aumenta a pressão de compactação. Use estas diretrizes como ponto de partida e ajuste com base em Compaction Queue Length, Average number of files in Region e Maximum number of files in Region:

Se o throughput de gravação exceder consistentemente esses limites, adicione recursos de CPU para manter a compactação em dia.

Pressão no MemStore

Métrica: Number of times exceeding the upper limit of Memstore (times)

O LindormTable grava dados primeiro em um MemStore (buffer na memória) e depois os libera para o disco. Quando o tráfego de gravação se concentra em poucos shards, os MemStores correspondentes enchem mais rápido do que conseguem liberar dados. Isso causa contrapressão de gravação e reduz o throughput.

Qualquer valor acima de 0 justifica investigação:

• Hotspot de gravação: as gravações concentram-se em poucos intervalos de chave primária. Redesenhe a chave primária usando um algoritmo de hash para distribuir as gravações uniformemente. Consulte Projetar chaves primárias para tabelas largas do Lindorm.

• TPS excedendo a capacidade da instância: a taxa total de gravação superou a capacidade da instância. Escale verticalmente ou adicione nós.