Bonnes pratiques pour surveiller la santé de Kafka avec les commandes intégrées

Les commandes intégrées de Kafka sont le moyen le plus rapide de répondre aux questions de base lors d'incidents : les partitions sont-elles dirigées, les répliques sont-elles synchronisées et les consommateurs sont-ils en retard ? Elles ne remplacent pas Prometheus, JMX ou une plateforme de surveillance gérée, mais elles sont excellentes pour des vérifications rapides depuis un hôte bastion ou un conteneur d'administration.

Les exemples ci-dessous utilisent --bootstrap-server, qui est le chemin client actuel pour les commandes d'administration Kafka.

Définir un environnement de commande propre

Conservez la liste des courtiers dans une variable pour que chaque commande soit reproductible :

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

Si votre cluster utilise TLS ou SASL, placez les paramètres client dans un fichier de propriétés et transmettez-le avec --command-config :

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

Vérifier la santé des sujets et des partitions

Commencez par kafka-topics.sh --describe. Un sujet sain doit avoir un leader pour chaque partition et une liste de répliques synchronisées correspondant au facteur de réplication attendu.

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

Recherchez ces champs :

• Leader : ne doit pas être none.
• Replicas : les courtiers assignés à la partition.
• Isr : les répliques actuellement synchronisées avec le leader.

Si Replicas a trois courtiers mais Isr n'en a qu'un, le sujet est sous-répliqué. Cela indique généralement un temps d'arrêt du courtier, une pression sur le disque, des problèmes réseau ou une réplique qui ne peut pas suivre.

Trouver rapidement les partitions sous-répliquées

Utilisez le filtre intégré lorsque vous avez besoin d'une vérification rapide à l'échelle du cluster :

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

Pas de sortie est une bonne nouvelle. Toute sortie mérite une enquête, en particulier pour les sujets avec min.insync.replicas configuré pour une durabilité renforcée.

Surveiller le retard des consommateurs

Le retard des consommateurs vous indique si un groupe de consommateurs suit le rythme des enregistrements produits.

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

Les colonnes importantes incluent :

• CURRENT-OFFSET : où le groupe a validé sa progression.
• LOG-END-OFFSET : le dernier décalage dans la partition.
• LAG : la différence entre les deux.
• CONSUMER-ID, HOST et CLIENT-ID : quel consommateur possède la partition.

De courts pics peuvent être normaux lors de déploiements ou de pics de trafic. Un retard soutenu signifie que le groupe a besoin d'attention : traitement lent, trop peu de consommateurs, déséquilibre des partitions, latence des dépendances en aval ou retards côté courtier dans les récupérations.

Lister les groupes de consommateurs actifs

Lorsque vous ne connaissez pas le nom du groupe, listez d'abord les groupes :

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

Inspectez ensuite le groupe qui correspond à l'application affectée.

Vérifier l'accessibilité de l'API du courtier

kafka-broker-api-versions.sh est un moyen simple de confirmer que votre client peut atteindre les courtiers et effectuer une poignée de main métadonnées/API.

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

Si cela échoue, vérifiez le DNS, les groupes de sécurité ou les pare-feu, les paramètres TLS/SASL et si les adresses des écouteurs annoncés sont accessibles depuis l'endroit où vous exécutez la commande.

Utiliser les vérifications CLI lors d'incidents

Un flux de triage pratique ressemble à ceci :

1. Exécutez kafka-broker-api-versions.sh pour confirmer la connectivité.
2. Exécutez kafka-topics.sh --describe --under-replicated-partitions pour vérifier la santé de la réplication.
3. Décrivez le sujet affecté et vérifiez les leaders et l'ISR.
4. Décrivez le groupe de consommateurs affecté et vérifiez le retard par partition.
5. Comparez les partitions lentes avec les journaux du courtier, du disque et de l'application.

À retenir

Les commandes intégrées de Kafka vous offrent un premier aperçu fiable de la santé du cluster. Gardez les configurations du client d'administration prêtes, utilisez --bootstrap-server et concentrez-vous sur les leaders, l'ISR, les partitions sous-répliquées et le retard des consommateurs. Une fois que la CLI montre où se situe le problème, les métriques et journaux plus approfondis du courtier sont beaucoup plus faciles à interpréter.