ApsaraMQ for Kafka:Perguntas frequentes sobre monitoramento e alertas

Verifique e atualize a versão secundária

1. Faça logon no console do ApsaraMQ for Kafka.

2. Na seção Resource Distribution da página Overview, selecione a região onde sua instância está localizada.

3. Na página Instances, clique em nome da instância.

4. Na página Instance Details, clique em aba Instance Information.

5. Na seção Basic Information, verifique se há uma Minor Version Update disponível ao lado do campo Minor Version.

6. Se houver uma atualização disponível, clique em Minor Version Update.

7. No painel exibido:

   1. Leia a seção Read Before Upgrade.

   2. Insira seu nome no campo Emergency Contact.

   3. Insira seu número de telefone no campo Emergency Contact Number.

   4. Insira o horário da atualização no campo Started At.

   5. Clique em OK.

Após a conclusão da atualização da versão secundária, a coluna Status no painel Alert Rules Associated with Resource muda de No data para um estado válido, como OK ou Alert.

Antes de começar

Interrompa todas as threads de consumidor no Group antes de tentar qualquer uma das soluções a seguir. Uma thread de consumidor ativa é aquela que assina mensagens usando o método subscribe. Se alguma thread ainda estiver confirmando offsets, os alertas persistirão independentemente de outras ações.

Redefinir offsets de consumidor (recomendado)

Esta abordagem funciona em todas as versões do servidor e é a maneira mais rápida de interromper os alertas.

1. Certifique-se de que o Group exista no console. Se você já o excluiu, recrie-o.

2. Desconecte todas as threads de consumidor.

3. No console do ApsaraMQ for Kafka, redefina o offset de consumidor para 0 nas partições onde deseja parar de rastrear o acúmulo de mensagens. Para obter as etapas, consulte Redefinir offsets de consumidor.

O sistema de alertas para de rastrear o acúmulo nessas partições após a redefinição.

Exclua o Group diretamente (versão do servidor 2.2.0 ou posterior)

Se sua instância executar a versão do servidor 2.2.0 ou posterior e o Group não tiver threads de consumidor ativas, exclua o Group diretamente. O servidor remove tanto o Group quanto seus offsets de consumidor.

Se os alertas continuarem após a exclusão, verifique se nenhuma thread de consumidor ainda está confirmando offsets.

Aguardar a expiração dos offsets (versões do servidor anteriores à 2.2.0)

Em versões mais antigas do servidor, os offsets de consumidor são limpos automaticamente após o término do período de retenção configurado, desde que nenhuma thread de consumidor os atualize. Para verificar ou ajustar o período de retenção, consulte Modificar configurações de mensagem.

Atualize a versão do servidor (versões do servidor anteriores à 2.2.0)

Se o Group não tiver threads de consumidor ativas, atualize a versão do servidor para 2.2.0 ou posterior. Após a atualização, recrie o Group e exclua-o para remover os offsets. Para obter as etapas, consulte Atualizar versões da instância.

Desativar alertas de acúmulo de mensagens

Se nenhuma das soluções anteriores resolver o problema, desative a regra de alerta para acúmulo de mensagens no CloudMonitor. Para mais detalhes, consulte CloudMonitor.

Nas versões do servidor 2.2.0 e posteriores, os offsets de consumidor não são excluídos enquanto o Group tiver pelo menos uma thread de consumidor ativa, mesmo que os offsets excedam o período de retenção. Para mais informações, consulte Por que os offsets de consumidor não são excluídos após expirarem?

Tópicos relacionados

• Por que um Group que não aparece no console consegue consumir mensagens?

• Acúmulo de mensagens ao usar o ApsaraMQ for Kafka

Accumulated messages = Maximum offset - Consumer offset

Como cada método calcula o acúmulo

Console (página Group Details)

A página Group Details busca o offset de consumidor e o offset máximo de cada partição em solicitações de chamada de procedimento remoto (RPC) separadas e consecutivas. Como o intervalo de tempo entre essas duas solicitações é pequeno, o resultado reflete fielmente o acúmulo real naquele momento.

Sistema de alertas

O sistema de alertas monitora todos os grupos de consumidores e tópicos em uma instância simultaneamente. Para reduzir a sobrecarga, ele agrupa as solicitações de offset: uma solicitação RPC busca os offsets de consumidor de todos os grupos, e outra busca os offsets máximos de todas as partições em todos os tópicos assinados. Isso reduz o número total de solicitações RPC de m x n x number of brokers para apenas number of brokers, onde m é o número de grupos de consumidores e n é o número de tópicos.

A contrapartida é um intervalo de tempo. Os produtores continuam enviando mensagens entre as duas solicitações em lote, então os offsets máximos aumentam enquanto os offsets de consumidor permanecem fixos. Isso infla o acúmulo calculado.

Exemplo: Suponha que uma partição tenha um offset de consumidor de 1.000 e um offset máximo de 1.050 quando a primeira solicitação em lote for executada. Quando a segunda solicitação em lote busca o offset máximo 200 ms depois, os produtores escreveram mais 30 mensagens, elevando o offset máximo para 1.080. O alerta relata 80 mensagens acumuladas (1.080 - 1.000), enquanto o console relataria um valor mais próximo de 50 (1.050 - 1.000).

Quando mensagens expiradas causam discrepâncias maiores

Se a taxa de consumo for muito lenta e o uso do disco for alto, a instância pode excluir mensagens antes que os consumidores as processem. Nessa situação, os offsets de consumidor de algumas partições ficam abaixo do offset mínimo da partição.

O ApsaraMQ for Kafka e o Apache Kafka open-source lidam de forma diferente com partições de mensagens expiradas:

Como o console exclui essas partições anômalas, mas o alerta as inclui, o valor do alerta é maior do que o exibido no console. As capturas de tela a seguir demonstram esse comportamento.

• Console e alerta mostram totais diferentes:

• O total do console exclui tópicos anômalos:

• O total do console exclui partições onde o offset de consumidor está abaixo do offset mínimo:

Em qual número confiar

• Para precisão pontual, use a página Group Details no console. Ela busca offsets por partição com um intervalo de tempo mínimo.

• Para monitoramento de tendências em vários grupos de consumidores, use o valor do alerta. Ele é otimizado para escala, não para precisão.

Uma pequena discrepância entre os dois é normal. Investigue apenas se a diferença for consistentemente grande ou crescente.

Suprimir alertas de acúmulo indesejados

• Ignorar alertas para tópicos específicos: Redefina os offsets de consumidor para 0 no grupo de consumidores dentro do console do ApsaraMQ for Kafka. O sistema de alertas deixará de relatar acúmulo para esses tópicos.

• Desativar completamente os alertas de acúmulo: Envie um ticket para desativar temporariamente o recurso de alerta de acúmulo de mensagens.

Quais métricas devo monitorar?

Concentre-se nas seguintes métricas com base no tipo da sua instância.

Por que alguns valores de métricas são imprecisos?

Três causas comuns:

• Baixo volume de tráfego. O sistema calcula cada métrica com base em uma fórmula específica. Quando o tráfego é baixo, pequenas flutuações produzem desvios desproporcionalmente grandes no resultado.

• Versão do cliente desatualizada. Bibliotecas de cliente Kafka mais antigas omitem parâmetros dos quais o sistema de monitoramento depende, o que distorce os valores relatados. Atualize para a versão mais recente do cliente para corrigir isso.

• Compressão de dados. Produtores comprimem dados para atender a requisitos específicos de transmissão ou armazenamento. Isso pode resultar em desvios nos dados de monitoramento.

Por que a saída de mensagens é zero quando a saída de solicitações é maior que zero?

Isso é normal, não um erro. Acontece quando os consumidores estão ativos, mas nenhuma nova mensagem foi publicada no broker.

Consumidores Kafka consultam continuamente o broker em busca de novas mensagens, mesmo quando nenhuma está disponível. Cada consulta registra uma solicitação de consumo, então InstanceReqsOutput e TopicReqsOutput incrementam a cada tentativa. Como nenhuma mensagem é realmente entregue, InstanceMessageOutput e TopicMessageOutput permanecem em zero.

Exemplo: Suponha que nenhum produtor esteja publicando mensagens enquanto um grupo de consumidores consulta o broker 50 vezes. TopicReqsOutput mostra 50, mas TopicMessageOutput mostra 0. Assim que um produtor começar a publicar novamente, ambas as métricas começarão a incrementar juntas.