Melhores Práticas para Monitorar a Saúde do Kafka com Comandos Integrados

Os comandos integrados do Kafka são a maneira mais rápida de responder a perguntas básicas durante incidentes: as partições estão lideradas, as réplicas estão sincronizadas e os consumidores estão atrasados? Eles não substituem Prometheus, JMX ou uma plataforma de monitoramento gerenciada, mas são excelentes para verificações rápidas a partir de um host bastião ou contêiner administrativo.

Os exemplos abaixo usam --bootstrap-server, que é o caminho atual do cliente para comandos de administração do Kafka.

Defina um Ambiente de Comando Limpo

Mantenha a lista de brokers em uma variável para que cada comando seja repetível:

export KAFKA_HOME=/opt/kafka
export BOOTSTRAP_SERVER="kafka1:9092,kafka2:9092,kafka3:9092"
cd "$KAFKA_HOME/bin"

Se seu cluster usar TLS ou SASL, coloque as configurações do cliente em um arquivo de propriedades e passe-o com --command-config:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --command-config /etc/kafka/admin-client.properties \
  --list

Verifique a Saúde do Tópico e da Partição

Comece com kafka-topics.sh --describe. Um tópico saudável deve ter um líder para cada partição e uma lista de réplicas em sincronia que corresponda ao fator de replicação esperado.

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --topic orders

Procure por estes campos:

• Leader: não deve ser none.
• Replicas: os brokers atribuídos para a partição.
• Isr: réplicas atualmente em sincronia com o líder.

Se Replicas tiver três brokers, mas Isr tiver apenas um, o tópico está sub-replicado. Isso geralmente aponta para inatividade do broker, pressão no disco, problemas de rede ou uma réplica que não consegue acompanhar.

Encontre Partições Sub-replicadas Rapidamente

Use o filtro integrado quando precisar de uma verificação rápida em todo o cluster:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --under-replicated-partitions

Nenhuma saída é uma boa notícia. Qualquer saída merece investigação, especialmente para tópicos com min.insync.replicas configurado para maior durabilidade.

Monitore o Atraso do Consumidor

O atraso do consumidor informa se um grupo de consumidores está acompanhando os registros produzidos.

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --group payments-worker

Colunas importantes incluem:

• CURRENT-OFFSET: onde o grupo confirmou o progresso.
• LOG-END-OFFSET: o offset mais recente na partição.
• LAG: a diferença entre os dois.
• CONSUMER-ID, HOST e CLIENT-ID: qual consumidor possui a partição.

Picos curtos podem ser normais durante implantações ou picos de tráfego. Atraso sustentado significa que o grupo precisa de atenção: processamento lento, poucos consumidores, desequilíbrio de partições, latência de dependência downstream ou atrasos de busca no lado do broker.

Liste Grupos de Consumidores Ativos

Quando você não sabe o nome do grupo, liste os grupos primeiro:

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --list

Em seguida, inspecione o grupo que corresponde ao aplicativo afetado.

Verifique a Acessibilidade da API do Broker

kafka-broker-api-versions.sh é uma maneira simples de confirmar que seu cliente pode alcançar os brokers e completar um handshake de metadados/API.

./kafka-broker-api-versions.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER"

Se isso falhar, verifique DNS, grupos de segurança ou firewalls, configurações TLS/SASL e se os endereços de listener anunciados são acessíveis a partir de onde você executa o comando.

Use Verificações CLI Durante Incidentes

Um fluxo de triagem prático se parece com isso:

1. Execute kafka-broker-api-versions.sh para confirmar a conectividade.
2. Execute kafka-topics.sh --describe --under-replicated-partitions para verificar a saúde da replicação.
3. Descreva o tópico afetado e verifique líderes e ISR.
4. Descreva o grupo de consumidores afetado e verifique o atraso por partição.
5. Compare as partições lentas com logs do broker, disco e aplicação.

Conclusão

Os comandos integrados do Kafka fornecem uma primeira visão confiável da saúde do cluster. Mantenha as configurações do cliente admin prontas, use --bootstrap-server e foque em líderes, ISR, partições sub-replicadas e atraso do consumidor. Depois que a CLI mostrar onde está o problema, métricas e logs mais profundos do broker são muito mais fáceis de interpretar.