Mejores Prácticas para Monitorear la Salud de Kafka con Comandos Integrados

Los comandos integrados de Kafka son la forma más rápida de responder preguntas básicas durante incidentes: ¿las particiones tienen líder?, ¿las réplicas están sincronizadas?, ¿los consumidores se están quedando atrás? No reemplazan a Prometheus, JMX o una plataforma de monitoreo administrada, pero son excelentes para verificaciones rápidas desde un host bastión o contenedor de administración.

Los ejemplos a continuación usan --bootstrap-server, que es la ruta actual del cliente para comandos de administración de Kafka.

Configurar un Entorno de Comandos Limpio

Mantenga la lista de brokers en una variable para que cada comando sea repetible:

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

Si su clúster usa TLS o SASL, coloque la configuración del cliente en un archivo de propiedades y páselo con --command-config:

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

Verificar la Salud de Temas y Particiones

Comience con kafka-topics.sh --describe. Un tema saludable debe tener un líder para cada partición y una lista de réplicas sincronizadas que coincida con el factor de replicación esperado.

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

Busque estos campos:

• Leader: no debe ser none.
• Replicas: los brokers asignados para la partición.
• Isr: réplicas actualmente sincronizadas con el líder.

Si Replicas tiene tres brokers pero Isr solo tiene uno, el tema está sub-replicado. Eso generalmente apunta a tiempo de inactividad del broker, presión de disco, problemas de red o una réplica que no puede mantenerse al día.

Encontrar Particiones Sub-replicadas Rápidamente

Use el filtro integrado cuando necesite una verificación rápida en todo el clúster:

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

Sin salida es una buena noticia. Cualquier salida merece investigación, especialmente para temas con min.insync.replicas configurado para mayor durabilidad.

Monitorear el Retraso del Consumidor

El retraso del consumidor indica si un grupo de consumidores se está manteniendo al día con los registros producidos.

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

Las columnas importantes incluyen:

• CURRENT-OFFSET: dónde el grupo ha confirmado el progreso.
• LOG-END-OFFSET: el último offset en la partición.
• LAG: la diferencia entre ambos.
• CONSUMER-ID, HOST y CLIENT-ID: qué consumidor posee la partición.

Picos cortos pueden ser normales durante despliegues o ráfagas de tráfico. Un retraso sostenido significa que el grupo necesita atención: procesamiento lento, pocos consumidores, desequilibrio de particiones, latencia de dependencias posteriores o retrasos en la obtención del lado del broker.

Listar Grupos de Consumidores Activos

Cuando no conozca el nombre del grupo, primero liste los grupos:

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

Luego inspeccione el grupo que corresponde a la aplicación afectada.

Verificar la Accesibilidad de la API del Broker

kafka-broker-api-versions.sh es una forma simple de confirmar que su cliente puede alcanzar los brokers y completar un handshake de metadatos/API.

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

Si esto falla, verifique DNS, grupos de seguridad o firewalls, configuraciones TLS/SASL y si las direcciones de listeners anunciadas son accesibles desde donde ejecuta el comando.

Usar Verificaciones CLI Durante Incidentes

Un flujo de triaje práctico se ve así:

1. Ejecute kafka-broker-api-versions.sh para confirmar la conectividad.
2. Ejecute kafka-topics.sh --describe --under-replicated-partitions para verificar la salud de la replicación.
3. Describa el tema afectado y verifique líderes e ISR.
4. Describa el grupo de consumidores afectado y verifique el retraso por partición.
5. Compare las particiones lentas con los registros del broker, disco y aplicación.

Conclusión

Los comandos integrados de Kafka le brindan una primera mirada confiable a la salud del clúster. Mantenga las configuraciones del cliente de administración listas, use --bootstrap-server y concéntrese en líderes, ISR, particiones sub-replicadas y retraso del consumidor. Una vez que la CLI muestra dónde está el problema, las métricas y registros más profundos del broker son mucho más fáciles de interpretar.