Monitoramento de Kafka: métricas, ferramentas e alertas

Quando o primeiro consumer lag explode às três da manhã em um cluster Kafka de produção, a equipe de plantão entende uma verdade rápida. Monitorar Kafka exige muito mais do que olhar CPU e memória dos brokers. O problema raramente está no host.

Apache Kafka funciona como o sistema nervoso de pipelines de dados, microsserviços e plataformas de eventos. Por isso, o monitoramento de Kafka precisa enxergar quatro camadas simultaneamente: broker, tópico, consumer group e host. Sem essa visão integrada, sintomas como atraso de mensagens, perda de eventos ou degradação de throughput viram corridas cegas.

Este guia mostra quais métricas observar, quais ferramentas combinar e quais alertas configurar para manter um cluster Kafka saudável em 2026. O conteúdo assume que você já conhece o básico de Kafka. Se precisar revisar arquitetura e fundamentos, leia primeiro o nosso guia completo de Apache Kafka.

Por que monitorar Kafka exige mais que monitoramento tradicional

Monitorar uma aplicação web típica significa olhar latência, taxa de erros e uso de CPU. Em Kafka, esse modelo cobre menos da metade do problema. O cluster envolve produtores, brokers, replicação, partições e consumidores, cada um com falhas e métricas próprias.

Brokers podem operar com CPU baixa e ainda assim entregar mensagens com atraso. Consumidores podem mostrar throughput normal e mesmo assim acumular lag. Por isso, o time precisa correlacionar várias camadas para descobrir onde o gargalo realmente está.

Além disso, Kafka roda em ambientes cada vez mais elásticos. Times que operam Kafka em stack de Kubernetes em produção precisam monitorar pods, volumes persistentes e throughput de rede. Esses elementos afetam diretamente o desempenho do broker.

As métricas críticas de Kafka organizadas por camada

Cada camada do cluster tem uma pergunta operacional principal. O broker responde “estou saudável?”. O tópico responde “estou recebendo e armazenando eventos?”. O consumer group responde “estou acompanhando a produção?”. O host responde “tenho recursos físicos para sustentar tudo isso?”.

A tabela abaixo organiza as métricas mais críticas por nível de severidade. Vale memorizar pelo menos as duas primeiras: elas aparecem em mais de 80% dos incidentes reais.

Por que essas métricas e não outras

Existem centenas de métricas JMX expostas pelo Kafka. A maioria gera ruído sem ajudar no diagnóstico. As métricas acima vieram de análise de incidentes reais e cobrem os cenários mais comuns: lag de consumo, replicação degradada, latência de produção e exaustão de disco.

Para uma visão mais ampla dos MBeans expostos, vale consultar a documentação oficial da Apache Software Foundation, que mantém a lista canônica de métricas do broker.

Consumer lag: a métrica que diz se o pipeline está saudável

Consumer lag é a diferença entre o último offset produzido em uma partição e o último offset consumido por um grupo de consumidores. Em outras palavras, é o número de mensagens pendentes para aquele grupo em determinado momento.

Lag zero raramente acontece em produção. O que importa é a tendência. Lag estável ou oscilando dentro de uma faixa conhecida indica saúde. Lag crescente de forma sustentada indica que os consumidores não acompanham a produção. Dessa forma, o tempo até esgotar a retenção do tópico vira o MTTR limite da equipe.

Para checar lag rapidamente pela CLI nativa do Kafka, o time pode rodar o comando abaixo direto no broker:

# Lista lag por partição em um consumer group
kafka-consumer-groups.sh --bootstrap-server broker1:9092 \
  --describe \
  --group meu-grupo-consumidor

A saída traz o lag por partição, o offset atual do consumidor e o offset mais recente do log. Em produção, esse comando serve para investigação pontual. Para monitoramento contínuo, a equipe precisa de algo automatizado, como veremos a seguir.

O que provoca consumer lag crescente

Causas comuns incluem picos de tráfego no produtor, código de consumo lento ou com bug, rebalanceamento de partições mal distribuídas, falha em broker que sustenta a partição lida e contenção de I/O no host. Cada causa tem sintoma e remediação distintas. Por isso, alertar apenas no lag bruto não basta para diagnosticar.

Stack de ferramentas para monitorar Apache Kafka

Não existe ferramenta única que cubra todas as necessidades de monitoramento de Kafka. A combinação mais comum em times maduros é Prometheus, Grafana e Burrow (ou Kafka Exporter) na camada open source. Para times que preferem suíte gerenciada, APMs comerciais como Datadog, New Relic e Conduktor entram em jogo.

A tabela a seguir compara as duas abordagens mais usadas no mercado, com vantagens e limitações de cada uma.

Por que Prometheus e Grafana viraram padrão

Prometheus expõe métricas via pull e armazena séries temporais com etiquetas, o que combina bem com brokers e exporters. Grafana visualiza essas séries em dashboards reutilizáveis. O dashboard da comunidade com ID 7589, por exemplo, cobre as principais métricas do Kafka.

A combinação é vendor-neutral e roda em qualquer ambiente: bare metal, cloud ou Kubernetes. Para times que já operam outras ferramentas de observabilidade modernas, integrar Kafka no mesmo painel reduz contexto fragmentado durante incidentes.

Quando faz sentido pagar por APM enterprise

APMs comerciais valem o investimento quando o time precisa correlacionar Kafka com aplicações, traces distribuídos e infraestrutura em um único pane of glass. Em ambientes que combinam Kafka com monitoramento de microsserviços, ferramentas como Datadog reduzem MTTR. Elas mostram a propagação de um problema do produtor ao consumidor final.

Vale lembrar que o Burrow continua sendo a referência open source para lag. O repositório público no GitHub, mantido pelo LinkedIn, ainda alimenta exporters Prometheus que muitos times usam em produção.

Alertas e SLOs: o que vale acordar o time de plantão

Métrica que não vira alerta nem dashboard é métrica esquecida. Métrica que vira alerta para tudo gera fadiga garantida. O equilíbrio está em alertar apenas sintomas com impacto direto no SLO, geralmente entre cinco e oito alertas por cluster Kafka.

A tabela a seguir traz a lista mínima de alertas recomendados, com thresholds prontos para copiar. Ajuste os valores conforme a taxa de produção e a tolerância do negócio.

SLOs para um cluster Kafka maduro

SLOs (Service Level Objectives) traduzem métricas técnicas em compromissos com o negócio. Para Kafka, três SLOs costumam ser suficientes: disponibilidade do cluster (por exemplo, 99,9% de requests respondidos em janelas de 30 dias), latência de produção p99 abaixo de 100ms e lag máximo aceitável para tópicos críticos.

Esses SLOs viram a base do error budget do time. Quando o orçamento de erro queima rápido, vale priorizar trabalho de confiabilidade em vez de novas features.

Para acompanhar a evolução, monte dashboards específicos por SLO. Bons indicadores de performance precisam ser visíveis a stakeholders técnicos e de negócio simultaneamente.

Cenários reais de troubleshooting com base em métricas

Métricas isoladas não diagnosticam nada. O valor surge quando uma combinação de sinais aponta para uma causa raiz. Veja três cenários que aparecem com frequência em clusters Kafka de produção.

Cenário 1: lag explode em um único consumer group

Sintomas observados: lag crescente apenas em um grupo específico, throughput do tópico estável, brokers com métricas saudáveis. Diagnóstico provável: bug no código do consumidor, deserialização lenta ou bloqueio em chamada externa síncrona.

Ação recomendada: olhar logs do consumidor, verificar tempo médio de processamento por mensagem e revisar dependências externas chamadas dentro do loop de consumo. Em geral, a correção está no código da aplicação, não no Kafka.

Cenário 2: URP > 0 e ISR encolhendo

Sintomas observados: under-replicated partitions positivo, in-sync replicas encolhendo, latência de produção subindo. Diagnóstico provável: um broker está com problema (rede, disco ou processo travado).

Ação recomendada: identificar qual broker é o líder das partições afetadas, verificar logs do broker e métricas de I/O do host. Em seguida, decidir entre restart controlado ou substituição do nó conforme a causa raiz.

Cenário 3: disco enche em um broker específico

Sintomas observados: utilização de disco acima de 80% em apenas um broker, demais brokers estáveis. Diagnóstico provável: tópicos com partições desbalanceadas para esse broker, ou retention configurado acima do esperado em algum tópico pesado.

Ação recomendada: rodar partition reassignment para redistribuir carga, ou ajustar retention dos tópicos pesados. Em ambientes de monitoramento de containers em produção, validar também volumes persistentes do pod do broker.

Boas práticas para monitorar Kafka em 2026

KRaft (Kafka Raft) tornou-se o modo de quorum padrão a partir do Kafka 3.5, eliminando a dependência do ZooKeeper. Para times migrando agora, é importante atualizar dashboards e alertas: métricas de ZooKeeper deixam de existir e novas métricas de controlador KRaft aparecem (active_controller_count, controller_queue_size).

Outras práticas que separam clusters maduros de clusters problemáticos:

– Retention curto (24 a 72h) para tópicos de alta volumetria evita explosão de disco e simplifica investigação
– Particionamento balanceado por chave reduz hot spots em brokers específicos
– Replication factor 3 como mínimo para tópicos críticos garante tolerância a falha de broker
– Alertas baseados em rate de mudança (não só valor absoluto) detectam degradação antes do incidente

Para configurar alertas no Prometheus baseados em rate de mudança, o exemplo abaixo dispara quando o lag agregado por consumer group ultrapassa o threshold definido.

# Alerta: consumer lag persistente em tópico crítico
sum by (consumergroup, topic) (
  kafka_consumergroup_lag{topic="pagamentos"}
) > 10000

Para times que tratam Kafka como parte central da arquitetura de eventos, vale também investir em um serviço de observabilidade que correlacione o cluster com produtores e consumidores no mesmo painel. A lista oficial de exporters Prometheus reúne integrações para boa parte da stack que costuma orbitar um cluster Kafka.

Conclusão

Monitoramento de Kafka maduro combina visão por camada (broker, tópico, consumer e host), ferramentas certas para cada cenário e alertas calibrados pelos SLOs do negócio. O ponto de partida é simples: identifique consumer lag, métricas JMX essenciais e URP. Depois, construa dashboards que respondam às perguntas que o time faz durante incidentes.

A partir daí, evolua para SLOs, error budgets e correlação com aplicações que produzem e consomem eventos. Times que tratam o cluster Kafka como parte estratégica da arquitetura ganham previsibilidade, reduzem MTTR e evitam que problemas de pipeline cheguem ao cliente final.

Se a sua equipe precisa estruturar ou amadurecer o monitoramento de Kafka com práticas comprovadas, a OpServices ajuda a desenhar dashboards, alertas e processos de operação 24×7. Fale com um especialista e leve a observabilidade do seu cluster ao próximo nível.