Estratégias Eficazes para Monitoramento e Alertas sobre a Saúde do Kafka

Falhas no Kafka raramente são misteriosas depois que acontecem. Um broker encheu seu disco, um grupo de consumidores ficou para trás, um tópico perdeu uma liderança limpa, um controlador começou a oscilar ou um caminho de rede ficou lento o suficiente para que os clientes atingissem o tempo limite. A parte difícil é capturar esses sinais cedo sem notificar as pessoas para cada pico inofensivo.

Um bom monitoramento do Kafka começa com um pequeno conjunto de perguntas sobre a saúde: os brokers podem atender solicitações, as partições podem eleger líderes, as réplicas estão atualizadas, os consumidores estão processando rápido o suficiente e o cluster está ficando sem CPU, memória, rede ou disco? As métricas abaixo são úteis porque mapeiam de volta para essas perguntas.

Por que o Monitoramento do Kafka é Crítico

A arquitetura distribuída do Kafka introduz vários pontos potenciais de falha e degradação de desempenho. Entender esses problemas potenciais e como monitorá-los é fundamental para manter um cluster saudável:

Latência de Dados: Um alto atraso do consumidor pode indicar que os consumidores não estão acompanhando a taxa do produtor, levando a dados desatualizados e impactando aplicações downstream.
Utilização de Recursos: CPU, memória ou espaço em disco insuficientes nos brokers podem levar à degradação do desempenho, falta de resposta ou até mesmo falhas no broker.
Desequilíbrio de Partições: A distribuição desigual de partições entre os brokers pode levar a alguns brokers sobrecarregados enquanto outros são subutilizados, impactando a taxa de transferência e a disponibilidade.
Disponibilidade do Broker: Falhas no broker podem levar à indisponibilidade ou perda de dados se não forem tratadas corretamente. Monitorar a saúde do broker é fundamental para a tolerância a falhas.
Problemas de Rede: Partições de rede ou alta latência entre brokers ou entre clientes e brokers podem impactar severamente o desempenho e a estabilidade do cluster.

Principais Métricas do Kafka para Monitorar

O monitoramento eficaz depende do rastreamento das métricas certas. Elas podem ser amplamente categorizadas em métricas de nível de broker, nível de tópico e nível de cliente.

Métricas de Nível de Broker

Essas métricas fornecem insights sobre a saúde e o desempenho de brokers Kafka individuais.

Métricas de Solicitação:
- kafka.network.RequestMetrics.RequestsPerSec (Taxa de solicitações recebidas)
- kafka.network.RequestMetrics.TotalTimeMs (Tempo total gasto processando solicitações)
- kafka.network.RequestMetrics.ResponseQueueTimeMs (Tempo gasto na fila de resposta)
- kafka.network.RequestMetrics.LocalTimeMs (Tempo gasto no broker)
- kafka.network.RequestMetrics.RemoteTimeMs (Tempo gasto se comunicando com outros brokers)
- kafka.network.RequestMetrics.TotalBytesInPerSec & TotalBytesOutPerSec (Taxa de transferência de rede)
Métricas de Log:
- kafka.log.Log.Size (Tamanho dos segmentos de log no disco)
- kafka.log.Log.N.MessagesPerSec (Taxa de mensagens sendo escritas em um segmento de log)
- kafka.log.Log.N.BytesPerSec (Taxa de bytes sendo escritos em um segmento de log)
- kafka.log.Log.N.LogFlushStats.LogFlushRateAndTimeMs (Taxa e tempo para liberar segmentos de log)
Métricas do Controlador: (Importante para eleição de líder e gerenciamento de partições)
- kafka.controller.Controller.ControllerStateChangesPerSec
- kafka.controller.Controller.LeaderChangesPerSec
Métricas JVM: (Essencial para entender o uso de recursos do broker)
- kafka.server:type=jvm,name=HeapMemoryUsage
- kafka.server:type=jvm,name=NonHeapMemoryUsage
- kafka.server:type=jvm,name=GarbageCollection
- kafka.server:type=jvm,name=Threads

Métricas de Nível de Tópico

Essas métricas focam no desempenho e na saúde de tópicos Kafka específicos.

Partições Sub-replicadas:
- kafka.cluster.PartitionReplicaCount.UnderReplicatedPartitions (Número de partições com menos réplicas do que o desejado)
- Alertar sobre esta métrica é crítico para a durabilidade e disponibilidade dos dados.
Partições Offline:
- kafka.cluster.PartitionState.OfflinePartitionsCount (Número de partições que não estão disponíveis)
- Uma contagem alta indica um problema sério com a liderança da partição ou disponibilidade do broker.
Taxa de Eleição de Líder:
- kafka.controller.Controller.LeaderChangesPerSec (Taxa de reeleições de líder)
- Um pico pode indicar instabilidade ou falhas no broker.

Métricas de Grupo de Consumidores

Essas métricas são vitais para entender o atraso do consumidor e a velocidade de processamento de suas aplicações.

Atraso do Consumidor: Esta não é frequentemente uma métrica direta do Kafka, mas calculada comparando o último offset produzido para um tópico com o último offset consumido por um grupo. Ferramentas de monitoramento geralmente fornecem esse cálculo.
- Alerta Crítico: Alto atraso do consumidor (por exemplo, excedendo um limite definido por um período sustentado) indica que os consumidores estão ficando para trás.
Métricas de Solicitação de Busca (da perspectiva do consumidor):
- kafka.consumer.Fetcher.MaxLag
- kafka.consumer.Fetcher.MinFetchWaitMs
- kafka.consumer.Fetcher.MaxFetchWaitMs

Implementando Soluções de Monitoramento

Várias ferramentas e abordagens podem ser usadas para monitorar o Kafka. A escolha geralmente depende da sua infraestrutura existente e necessidades operacionais.

JMX e Prometheus

Os brokers Kafka expõem uma riqueza de métricas via JMX (Java Management Extensions). Ferramentas como Prometheus podem coletar essas métricas JMX usando um adaptador como jmx_exporter.

Habilitar JMX: O Kafka normalmente tem JMX habilitado por padrão. Certifique-se de que a porta JMX esteja acessível.
Configurar jmx_exporter: Baixe e configure o jmx_exporter para expor as métricas JMX do Kafka em um formato compatível com Prometheus. Você precisará de um arquivo YAML de configuração especificando quais MBeans coletar. Exemplo de trecho de configuração do jmx_exporter para JMX do Kafka: jmx_exporter/example_configs/kafka-2-0-0.yml (frequentemente encontrado no repositório jmx_exporter)
Configurar Prometheus: Adicione um alvo na sua configuração do Prometheus para coletar o endpoint exposto pelo jmx_exporter executado junto com seus brokers Kafka.
```
scrape_configs:
  - job_name: 'kafka'
    static_configs:
      - targets: ['<kafka-broker-ip>:9404'] # Porta padrão para jmx_exporter
```
Visualizar com Grafana: Use o Grafana para construir painéis exibindo essas métricas do Prometheus. Painéis Kafka pré-construídos estão prontamente disponíveis no Grafana Labs.

Ferramentas de Monitoramento Específicas para Kafka

Kafka Manager (antigo Yahoo Kafka Manager): Uma ferramenta web popular para gerenciar clusters Kafka. Ela fornece status do broker, inspeção de tópicos, monitoramento de atraso do consumidor e gerenciamento de partições.
CMAK (Cluster Manager for Apache Kafka): Um fork do Kafka Manager, mantido ativamente e oferecendo recursos semelhantes.
Lenses.io / Confluent Control Center: Ofertas comerciais que fornecem recursos avançados de monitoramento, gerenciamento e visualização de dados do Kafka.
Stacks de Monitoramento Kafka de Código Aberto: Combinações como stack ELK (Elasticsearch, Logstash, Kibana) com logs do Kafka, ou stack TICK (Telegraf, InfluxDB, Chronograf, Kapacitor) para dados de séries temporais.

Configurando Alertas Eficazes

Depois de coletar as métricas, o próximo passo é configurar alertas para condições críticas. Sua estratégia de alerta deve focar em problemas que impactam diretamente a disponibilidade da aplicação, integridade dos dados ou desempenho.

Alertas Críticos para Configurar:

Partições Sub-replicadas > 0: Este é um alerta de alta prioridade indicando potencial perda ou indisponibilidade de dados. Investigação imediata é necessária.
Contagem de Partições Offline > 0: Semelhante a partições sub-replicadas, isso significa partições que estão completamente indisponíveis.
Alto Atraso do Consumidor: Defina um limite com base na tolerância da sua aplicação para dados desatualizados. Alerte quando o atraso exceder este limite por uma duração específica (por exemplo, 5 minutos). Exemplo PromQL (conceitual para Prometheus/Grafana):
```
avg_over_time(kafka_consumergroup_lag_max{group="seu-grupo-consumidor"}[5m]) > 1000
```
Nota: O nome exato da métrica e como o atraso é calculado dependerá da sua configuração de monitoramento (por exemplo, usando métricas próprias do Kafka, kafka-exporter ou métricas do lado do cliente).
Uso de CPU/Memória/Disco do Broker: Alerte quando a utilização exceder limites predefinidos (por exemplo, 80% para CPU/memória, 90% para disco). O espaço em disco é particularmente crítico para o Kafka.
Alta Latência de Solicitação: Alerte sobre aumentos sustentados em RequestMetrics.TotalTimeMs ou tipos específicos de solicitação (por exemplo, Produzir, Buscar).
Reinicialização/Indisponibilidade do Broker: Configure alertas para quando um broker Kafka se tornar inacessível ou parar de relatar métricas.
Picos na Taxa de Eleição de Líder: Alerte sobre taxas anormalmente altas de eleições de líder, o que pode indicar instabilidade.

Integração de Ferramentas de Alerta

Sua configuração do Prometheus pode integrar-se com gerenciadores de alerta como o Alertmanager. O Alertmanager lida com deduplicação, agrupamento e roteamento de alertas para vários canais de notificação como e-mail, Slack, PagerDuty, etc.

Exemplo de Configuração do Alertmanager (alertmanager.yml):

route:
  group_by: ['alertname', 'cluster', 'service']
  receiver: 'default-receiver'
  routes:
    - receiver: 'critical-ops'
      match_re:
        severity: 'critical'
      continue: true

receivers:
  - name: 'default-receiver'
    slack_configs:
      - channel: '#kafka-alerts'

  - name: 'critical-ops'
    slack_configs:
      - channel: '#kafka-critical'
    pagerduty_configs:
      - service_key: '<sua-chave-pagerduty>'

Melhores Práticas para Monitoramento e Alertas do Kafka

Estabeleça Linhas de Base: Entenda o comportamento operacional normal do seu cluster Kafka. Isso ajuda a definir limites de alerta significativos e identificar anomalias.
Hierarquize Seus Alertas: Diferencie entre alertas críticos que exigem ação imediata e alertas informativos que precisam de revisão, mas não necessariamente exigem uma resposta de emergência.
Automatize Ações: Para problemas comuns (por exemplo, avisos de espaço em disco), considere automatizar etapas de remediação onde for seguro.
Monitore a Camada de Metadados: Clusters Kafka mais antigos comumente dependem do ZooKeeper, enquanto implantações mais novas podem usar o modo KRaft. Monitore o quórum de metadados que seu cluster realmente usa.
Monitore a Rede: Certifique-se de que a conectividade de rede e a latência entre brokers e clientes estejam dentro dos limites aceitáveis.
Revise os Painéis Regularmente: Não confie apenas em alertas. Revise regularmente seus painéis de monitoramento para identificar tendências e problemas potenciais antes que eles acionem alertas.
Teste Seus Alertas: Teste periodicamente seu sistema de alerta para garantir que as notificações estão sendo enviadas corretamente e alcançando as pessoas certas.

Alerte sobre Sintomas que os Leitores Podem Ação

O Kafka expõe muitas métricas, e é fácil construir um painel que parece impressionante, mas não ajuda durante um incidente. Comece com alertas que têm uma ação clara do operador.

UnderReplicatedPartitions > 0 é acionável porque significa que pelo menos uma partição tem menos réplicas em sincronia do que o esperado. A primeira verificação é a saúde do broker, depois disco, rede e atraso do buscador de réplicas. Se limpar rapidamente durante uma reinicialização contínua, pode ser esperado. Se permanecer diferente de zero, trate como um risco de durabilidade e disponibilidade.

OfflinePartitionsCount > 0 é mais urgente. Uma partição sem um líder ativo não pode servir tráfego normal de produção ou busca. Este alerta deve incluir o contexto do cluster e do broker, e deve notificar para clusters de produção.

O atraso do consumidor é importante, mas precisa de nuance. Um atraso de 10.000 registros pode ser inofensivo para um tópico de lote noturno de baixa prioridade e sério para um pipeline de detecção de fraude. Alerte sobre o atraso relativo ao propósito do grupo de consumidores: atraso sustentado, atraso aumentando mais rápido do que os consumidores podem se recuperar, ou tempo estimado de atraso quando suas ferramentas podem calculá-lo.

Alertas de disco devem disparar antes que o Kafka não tenha espaço para escrever. Os brokers Kafka são sistemas pesados de disco por design, e discos cheios podem causar problemas em cascata. Combine alertas de uso de disco com contexto do diretório de log para que a pessoa de plantão possa ver se o problema é um broker, um ponto de montagem ou uma política de retenção em todo o cluster.

Um Layout de Painel Prático

Um painel Kafka útil geralmente tem camadas. A linha superior deve responder se o cluster está servindo tráfego: contagem de brokers, partições offline, partições sub-replicadas, mudanças de controlador, latência de solicitação e taxas de erro de produção/busca.

A próxima linha deve mostrar taxa de transferência e pressão: bytes recebidos, bytes enviados, solicitações de produção, solicitações de busca, processador de rede ocioso, manipulador de solicitação ocioso, CPU, memória, uso de disco e E/S de disco. Esses painéis ajudam você a ver se um pico de latência corresponde a uma restrição real de recursos.

A terceira linha deve focar na replicação: atraso do buscador de réplicas, eventos de redução/expansão de réplicas em sincronia, taxa de eleição de líder e distribuição de partições por broker. Se um broker tem muito mais líderes ou partições quentes do que o resto, o cluster pode parecer saudável no geral enquanto um nó está sobrecarregado.

A quarta linha deve focar nos consumidores: atraso por grupo e tópico, registros consumidos por segundo, taxa de rebalanceamento quando disponível e métricas de erro do consumidor da instrumentação da aplicação. As métricas do broker não podem dizer se um consumidor está preso dentro de uma gravação lenta no banco de dados depois de buscar mensagens.

Onde as Verificações de Linha de Comando Ainda Ajudam

Mesmo com painéis, as ferramentas de linha de comando do Kafka são úteis para confirmar o que o cluster acredita.

Verifique o estado da partição do tópico:

kafka-topics.sh --bootstrap-server broker1:9092 --describe --topic orders

Procure por partições com líderes ausentes, réplicas que não estão no ISR ou colocação desigual de líderes.

Verifique o atraso do consumidor:

kafka-consumer-groups.sh \
  --bootstrap-server broker1:9092 \
  --describe \
  --group billing-worker

A saída ajuda você a separar "todo o grupo está atrasado" de "uma partição está presa". Uma partição presa geralmente aponta para uma mensagem venenosa, uma chave quente ou uma única instância de consumidor que não está saudável.

Verifique as versões da API do broker quando os clientes estiverem se comportando de forma estranha:

kafka-broker-api-versions.sh --bootstrap-server broker1:9092

Incompatibilidades de versão não são a causa mais comum de incidentes de saúde, mas podem explicar o comportamento do cliente após atualizações ou implantações de versão mista.

Evitando Alertas Barulhentos do Kafka

Alertas barulhentos geralmente vêm de limites copiados de outro cluster. As cargas de trabalho do Kafka variam demais para números universais. Um fluxo de pagamentos, um fluxo intenso de métricas e um tópico de importação em lote têm tolerância de latência, taxa de transferência, contagens de partição e expectativas de retenção diferentes.

Use janelas sustentadas para alertas que podem aumentar naturalmente. Por exemplo, o atraso do consumidor pode precisar permanecer acima do limite por vários minutos antes de notificar. Partições sub-replicadas em produção podem merecer uma janela mais curta. Alertas de broker inativo devem considerar manutenção planejada, mas não devem ser ocultados tão agressivamente que falhas reais passem despercebidas.

Cada notificação deve ter um provável proprietário. Disco do broker cheio pertence à equipe de plataforma ou operações. Atraso do consumidor para billing-worker pode pertencer à equipe de aplicação. Se todos os alertas do Kafka forem roteados para um canal sem propriedade, as pessoas aprenderão a ignorá-los.

Camada de Metadados e Nuances de Versão

Muitos clusters Kafka existentes ainda usam ZooKeeper, e esses clusters precisam de monitoramento do ZooKeeper: saúde do quórum, latência, disco, saúde JVM e contagem de conexões. Clusters Kafka usando o modo KRaft precisam de monitoramento para o quórum do controlador. A ideia operacional é a mesma: se a camada de metadados não está saudável, a saúde do broker pode degradar de maneiras que parecem não relacionadas à primeira vista.

Cuidado com orientações antigas que dizem que todo cluster Kafka depende do ZooKeeper. Isso era verdade por muitos anos, mas implantações mais novas do Kafka podem não usá-lo. Seu runbook deve corresponder ao cluster que você realmente executa.

Runbooks Importam Mais do que Painéis Perfeitos

Um alerta sem um runbook deixa a pessoa de plantão adivinhando. Para cada alerta crítico, escreva as primeiras verificações, as causas comuns e o caminho de escalonamento. Para partições sub-replicadas, o runbook pode dizer: verifique a acessibilidade do broker, inspecione o uso do disco, inspecione erros de rede, verifique implantações ou reinicializações recentes, identifique tópicos afetados e decida se deve pausar a manutenção.

Para atraso do consumidor, o runbook pode dizer: identifique se o atraso é em todas as partições ou em uma partição, verifique a saúde da implantação do consumidor, verifique erros recentes da aplicação, inspecione dependências downstream e procure por rebalanceamentos. Se uma única partição estiver presa, encontre o offset atual e inspecione a mensagem com segurança usando ferramentas internas, em vez de pular offsets cegamente.

Um bom monitoramento não elimina incidentes. Ele torna as primeiras decisões mais rápidas e menos emocionais.

O monitoramento da saúde do Kafka funciona quando cada métrica se conecta a uma pergunta operacional. As partições estão disponíveis? As réplicas estão atualizadas? Os consumidores estão acompanhando o ritmo? Os brokers estão ficando sem recursos? Os controladores ou serviços de metadados estão estáveis? Construa painéis e alertas em torno dessas perguntas, depois mantenha os limites vinculados à sua própria carga de trabalho, em vez dos padrões de outra pessoa.