Stratégies efficaces pour la surveillance et les alertes sur la santé de Kafka

Les défaillances de Kafka sont rarement mystérieuses après coup. Un courtier a rempli son disque, un groupe de consommateurs a pris du retard, un sujet a perdu une direction propre, un contrôleur a commencé à osciller, ou un chemin réseau est devenu suffisamment lent pour que les clients expirent. La partie difficile est de détecter ces signaux tôt sans appeler les gens pour chaque pic inoffensif.

Une bonne surveillance de Kafka commence par un petit ensemble de questions sur la santé : les courtiers peuvent-ils répondre aux requêtes, les partitions peuvent-elles élire des leaders, les répliques sont-elles à jour, les consommateurs traitent-ils assez vite, et le cluster manque-t-il de CPU, mémoire, réseau ou disque ? Les métriques ci-dessous sont utiles car elles correspondent à ces questions.

Pourquoi la surveillance de Kafka est cruciale

L'architecture distribuée de Kafka introduit plusieurs points potentiels de défaillance et de dégradation des performances. Comprendre ces problèmes potentiels et comment les surveiller est essentiel pour maintenir un cluster sain :

Latence des données : Un retard élevé des consommateurs peut indiquer que les consommateurs ne suivent pas le rythme des producteurs, entraînant des données obsolètes et impactant les applications en aval.
Utilisation des ressources : Un CPU, une mémoire ou un espace disque insuffisant sur les courtiers peut entraîner une dégradation des performances, une absence de réponse, voire des plantages de courtiers.
Déséquilibre des partitions : Une distribution inégale des partitions entre les courtiers peut entraîner une surcharge de certains courtiers tandis que d'autres sont sous-utilisés, impactant le débit et la disponibilité.
Disponibilité des courtiers : Les défaillances de courtiers peuvent entraîner une indisponibilité ou une perte de données si elles ne sont pas gérées correctement. La surveillance de la santé des courtiers est primordiale pour la tolérance aux pannes.
Problèmes réseau : Les partitions réseau ou une latence élevée entre les courtiers ou entre les clients et les courtiers peuvent gravement impacter les performances et la stabilité du cluster.

Métriques clés de Kafka à surveiller

Une surveillance efficace repose sur le suivi des bonnes métriques. Celles-ci peuvent être largement classées en métriques au niveau des courtiers, des sujets et des clients.

Métriques au niveau des courtiers

Ces métriques fournissent des informations sur la santé et les performances des courtiers Kafka individuels.

Métriques de requêtes :
- kafka.network.RequestMetrics.RequestsPerSec (Taux de requêtes entrantes)
- kafka.network.RequestMetrics.TotalTimeMs (Temps total passé à traiter les requêtes)
- kafka.network.RequestMetrics.ResponseQueueTimeMs (Temps passé dans la file d'attente des réponses)
- kafka.network.RequestMetrics.LocalTimeMs (Temps passé sur le courtier)
- kafka.network.RequestMetrics.RemoteTimeMs (Temps passé à communiquer avec d'autres courtiers)
- kafka.network.RequestMetrics.TotalBytesInPerSec & TotalBytesOutPerSec (Débit réseau)
Métriques de journal :
- kafka.log.Log.Size (Taille des segments de journal sur le disque)
- kafka.log.Log.N.MessagesPerSec (Taux de messages écrits dans un segment de journal)
- kafka.log.Log.N.BytesPerSec (Taux d'octets écrits dans un segment de journal)
- kafka.log.Log.N.LogFlushStats.LogFlushRateAndTimeMs (Taux et temps de vidage des segments de journal)
Métriques du contrôleur : (Importantes pour l'élection du leader et la gestion des partitions)
- kafka.controller.Controller.ControllerStateChangesPerSec
- kafka.controller.Controller.LeaderChangesPerSec
Métriques JVM : (Essentielles pour comprendre l'utilisation des ressources du courtier)
- 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étriques au niveau des sujets

Ces métriques se concentrent sur les performances et la santé de sujets Kafka spécifiques.

Partitions sous-répliquées :
- kafka.cluster.PartitionReplicaCount.UnderReplicatedPartitions (Nombre de partitions avec moins de répliques que souhaité)
- L'alerte sur cette métrique est cruciale pour la durabilité et la disponibilité des données.
Partitions hors ligne :
- kafka.cluster.PartitionState.OfflinePartitionsCount (Nombre de partitions qui ne sont pas disponibles)
- Un nombre élevé indique un problème sérieux avec la direction des partitions ou la disponibilité des courtiers.
Taux d'élection du leader :
- kafka.controller.Controller.LeaderChangesPerSec (Taux de réélections du leader)
- Un pic peut indiquer une instabilité ou des défaillances de courtiers.

Métriques des groupes de consommateurs

Ces métriques sont essentielles pour comprendre le retard des consommateurs et la vitesse de traitement de vos applications.

Retard du consommateur : Ce n'est souvent pas une métrique Kafka directe mais calculée en comparant le dernier décalage produit vers un sujet avec le dernier décalage consommé par un groupe. Les outils de surveillance fournissent généralement ce calcul.
- Alerte critique : Un retard élevé du consommateur (par exemple, dépassant un seuil défini pendant une période prolongée) indique que les consommateurs prennent du retard.
Métriques de requêtes de récupération (du point de vue du consommateur) :
- kafka.consumer.Fetcher.MaxLag
- kafka.consumer.Fetcher.MinFetchWaitMs
- kafka.consumer.Fetcher.MaxFetchWaitMs

Mise en œuvre de solutions de surveillance

Plusieurs outils et approches peuvent être utilisés pour surveiller Kafka. Le choix dépend souvent de votre infrastructure existante et de vos besoins opérationnels.

JMX et Prometheus

Les courtiers Kafka exposent une multitude de métriques via JMX (Java Management Extensions). Des outils comme Prometheus peuvent récupérer ces métriques JMX en utilisant un adaptateur comme jmx_exporter.

Activer JMX : Kafka a généralement JMX activé par défaut. Assurez-vous que le port JMX est accessible.
Configurer jmx_exporter : Téléchargez et configurez jmx_exporter pour exposer les métriques JMX de Kafka dans un format compatible avec Prometheus. Vous aurez besoin d'un fichier de configuration YAML spécifiant les MBeans à récupérer. Exemple d'extrait de configuration jmx_exporter pour JMX Kafka : jmx_exporter/example_configs/kafka-2-0-0.yml (souvent trouvé dans le dépôt jmx_exporter)
Configurer Prometheus : Ajoutez une cible dans votre configuration Prometheus pour récupérer le point de terminaison exposé par jmx_exporter fonctionnant aux côtés de vos courtiers Kafka.
```
scrape_configs:
  - job_name: 'kafka'
    static_configs:
      - targets: ['<kafka-broker-ip>:9404'] # Port par défaut pour jmx_exporter
```
Visualiser avec Grafana : Utilisez Grafana pour créer des tableaux de bord affichant ces métriques Prometheus. Des tableaux de bord Kafka préconstruits sont facilement disponibles sur Grafana Labs.

Outils de surveillance spécifiques à Kafka

Kafka Manager (anciennement Yahoo Kafka Manager) : Un outil web populaire pour gérer les clusters Kafka. Il fournit l'état des courtiers, l'inspection des sujets, la surveillance du retard des consommateurs et la gestion des partitions.
CMAK (Cluster Manager for Apache Kafka) : Un fork de Kafka Manager, activement maintenu et offrant des fonctionnalités similaires.
Lenses.io / Confluent Control Center : Offres commerciales qui fournissent des capacités avancées de surveillance, de gestion et de visualisation des données Kafka.
Stacks de surveillance Kafka open source : Combinaisons comme la pile ELK (Elasticsearch, Logstash, Kibana) avec les journaux Kafka, ou la pile TICK (Telegraf, InfluxDB, Chronograf, Kapacitor) pour les données de séries temporelles.

Configuration d'alertes efficaces

Une fois que les métriques sont collectées, l'étape suivante consiste à configurer des alertes pour les conditions critiques. Votre stratégie d'alerte doit se concentrer sur les problèmes qui impactent directement la disponibilité des applications, l'intégrité des données ou les performances.

Alertes critiques à configurer :

Partitions sous-répliquées > 0 : C'est une alerte haute priorité indiquant une perte ou une indisponibilité potentielle des données. Une enquête immédiate est requise.
Nombre de partitions hors ligne > 0 : Similaire aux partitions sous-répliquées, cela signifie que les partitions sont totalement indisponibles.
Retard élevé du consommateur : Définissez un seuil basé sur la tolérance de votre application aux données obsolètes. Alertez lorsque le retard dépasse ce seuil pendant une durée spécifique (par exemple, 5 minutes). Exemple PromQL (conceptuel pour Prometheus/Grafana) :
```
avg_over_time(kafka_consumergroup_lag_max{group="votre-groupe-consommateur"}[5m]) > 1000
```
Remarque : Le nom exact de la métrique et la façon dont le retard est calculé dépendront de votre configuration de surveillance (par exemple, en utilisant les propres métriques de Kafka, kafka-exporter ou des métriques côté client).
Utilisation CPU/Mémoire/Disque du courtier : Alertez lorsque l'utilisation dépasse des seuils prédéfinis (par exemple, 80 % pour CPU/mémoire, 90 % pour disque). L'espace disque est particulièrement critique pour Kafka.
Latence élevée des requêtes : Alertez sur les augmentations soutenues de RequestMetrics.TotalTimeMs ou de types de requêtes spécifiques (par exemple, Produire, Récupérer).
Redémarrage/Indisponibilité du courtier : Configurez des alertes pour lorsqu'un courtier Kafka devient inaccessible ou cesse de signaler des métriques.
Pics du taux d'élection du leader : Alertez sur des taux anormalement élevés d'élections de leaders, ce qui peut indiquer une instabilité.

Intégration des outils d'alerte

Votre configuration Prometheus peut s'intégrer à des gestionnaires d'alertes comme Alertmanager. Alertmanager gère la déduplication, le regroupement et le routage des alertes vers différents canaux de notification comme l'email, Slack, PagerDuty, etc.

Exemple de configuration d'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: '<votre-clé-pagerduty>'

Meilleures pratiques pour la surveillance et les alertes Kafka

Établir des bases de référence : Comprenez le comportement opérationnel normal de votre cluster Kafka. Cela aide à définir des seuils d'alerte significatifs et à identifier les anomalies.
Hiérarchiser vos alertes : Différenciez les alertes critiques nécessitant une action immédiate des alertes informatives qui nécessitent une révision mais ne nécessitent pas nécessairement une réponse d'urgence.
Automatiser les actions : Pour les problèmes courants (par exemple, les avertissements d'espace disque), envisagez d'automatiser les étapes de correction lorsque cela est sûr.
Surveiller la couche de métadonnées : Les anciens clusters Kafka dépendent généralement de ZooKeeper, tandis que les déploiements plus récents peuvent utiliser le mode KRaft. Surveillez le quorum de métadonnées que votre cluster utilise réellement.
Surveiller le réseau : Assurez-vous que la connectivité réseau et la latence entre les courtiers et les clients sont dans des limites acceptables.
Examiner régulièrement les tableaux de bord : Ne vous fiez pas uniquement aux alertes. Examinez régulièrement vos tableaux de bord de surveillance pour repérer les tendances et les problèmes potentiels avant qu'ils ne déclenchent des alertes.
Tester vos alertes : Testez périodiquement votre système d'alerte pour vous assurer que les notifications sont envoyées correctement et atteignent les bonnes personnes.

Alerter sur les symptômes sur lesquels les lecteurs peuvent agir

Kafka expose beaucoup de métriques, et il est facile de construire un tableau de bord qui a l'air impressionnant mais qui n'aide pas lors d'un incident. Commencez par des alertes qui ont une action claire pour l'opérateur.

UnderReplicatedPartitions > 0 est exploitable car cela signifie qu'au moins une partition a moins de répliques synchronisées que prévu. La première vérification est la santé du courtier, puis le disque, le réseau et le retard du récupérateur de répliques. Si cela se résout rapidement lors d'un redémarrage progressif, cela peut être attendu. Si cela reste non nul, traitez-le comme un risque de durabilité et de disponibilité.

OfflinePartitionsCount > 0 est plus urgent. Une partition sans leader actif ne peut pas servir le trafic normal de production ou de récupération. Cette alerte doit inclure le contexte du cluster et du courtier, et elle doit appeler pour les clusters de production.

Le retard du consommateur est important, mais il nécessite des nuances. Un retard de 10 000 enregistrements peut être inoffensif pour un sujet de lot nocturne de faible priorité et grave pour un pipeline de détection de fraude. Alertez sur le retard par rapport à l'objectif du groupe de consommateurs : retard soutenu, retard augmentant plus vite que les consommateurs ne peuvent récupérer, ou temps estimé de retard lorsque vos outils peuvent le calculer.

Les alertes de disque doivent se déclencher avant que Kafka n'ait plus d'espace pour écrire. Les courtiers Kafka sont des systèmes lourds en disque par conception, et les disques pleins peuvent provoquer des problèmes en cascade. Associez les alertes d'utilisation du disque au contexte du répertoire de journal afin que la personne de garde puisse voir si le problème concerne un courtier, un point de montage ou une politique de rétention sur l'ensemble du cluster.

Une disposition pratique du tableau de bord

Un tableau de bord Kafka utile a généralement plusieurs couches. La première ligne doit répondre à la question de savoir si le cluster sert du trafic : nombre de courtiers, partitions hors ligne, partitions sous-répliquées, changements de contrôleur, latence des requêtes et taux d'erreur de production/récupération.

La ligne suivante doit montrer le débit et la pression : octets entrants, octets sortants, requêtes de production, requêtes de récupération, inactivité du processeur réseau, inactivité du gestionnaire de requêtes, CPU, mémoire, utilisation du disque et E/S disque. Ces panneaux vous aident à voir si un pic de latence correspond à une contrainte de ressource réelle.

La troisième ligne doit se concentrer sur la réplication : retard du récupérateur de répliques, événements de rétrécissement/expansion des répliques synchronisées, taux d'élection du leader et distribution des partitions par courtier. Si un courtier a beaucoup plus de leaders ou de partitions chaudes que les autres, le cluster peut sembler sain dans l'ensemble tandis qu'un nœud est surchargé.

La quatrième ligne doit se concentrer sur les consommateurs : retard par groupe et sujet, enregistrements consommés par seconde, taux de rééquilibrage lorsque disponible, et métriques d'erreur des consommateurs provenant de l'instrumentation de l'application. Les métriques du courtier ne peuvent pas vous dire si un consommateur est bloqué à l'intérieur d'une écriture de base de données lente après avoir récupéré des messages.

Où les vérifications en ligne de commande aident encore

Même avec des tableaux de bord, les outils en ligne de commande de Kafka sont utiles pour confirmer ce que le cluster croit.

Vérifier l'état des partitions du sujet :

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

Recherchez les partitions avec des leaders manquants, des répliques qui ne sont pas dans l'ISR, ou un placement de leader inégal.

Vérifier le retard du consommateur :

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

La sortie vous aide à séparer "tout le groupe est en retard" de "une partition est bloquée". Une partition bloquée indique souvent un message empoisonné, une clé chaude ou une instance de consommateur unique qui est malsaine.

Vérifier les versions de l'API du courtier lorsque les clients se comportent étrangement :

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

Les incompatibilités de version ne sont pas la cause la plus courante des incidents de santé, mais elles peuvent expliquer le comportement des clients après des mises à niveau ou des déploiements de versions mixtes.

Éviter les alertes Kafka bruyantes

Les alertes bruyantes proviennent généralement de seuils copiés d'un autre cluster. Les charges de travail Kafka varient trop pour des nombres universels. Un flux de paiements, un déluge de métriques et un sujet d'importation par lots ont des tolérances de latence, des débits, des nombres de partitions et des attentes de rétention différents.

Utilisez des fenêtres soutenues pour les alertes qui peuvent augmenter naturellement. Par exemple, le retard du consommateur peut devoir rester au-dessus du seuil pendant plusieurs minutes avant d'appeler. Les partitions sous-répliquées en production peuvent mériter une fenêtre plus courte. Les alertes de courtier en panne doivent prendre en compte la maintenance planifiée, mais elles ne doivent pas être cachées si agressivement que les vraies défaillances passent inaperçues.

Chaque page doit avoir un propriétaire probable. Le disque plein du courtier appartient à l'équipe de plateforme ou d'exploitation. Le retard du consommateur pour billing-worker peut appartenir à l'équipe d'application. Si toutes les alertes Kafka sont routées vers un seul canal sans propriété, les gens apprendront à les ignorer.

Nuance de la couche de métadonnées et de version

De nombreux clusters Kafka existants utilisent encore ZooKeeper, et ces clusters ont besoin d'une surveillance ZooKeeper : santé du quorum, latence, disque, santé JVM et nombre de connexions. Les clusters Kafka utilisant le mode KRaft ont besoin d'une surveillance du quorum du contrôleur à la place. L'idée opérationnelle est la même : si la couche de métadonnées est malsaine, la santé du courtier peut se dégrader d'une manière qui semble sans rapport au début.

Soyez prudent avec les anciens conseils qui disent que chaque cluster Kafka repose sur ZooKeeper. C'était vrai pendant de nombreuses années, mais les déploiements Kafka plus récents peuvent ne pas l'utiliser. Votre manuel d'exploitation doit correspondre au cluster que vous exécutez réellement.

Les manuels d'exploitation comptent plus que les tableaux de bord parfaits

Une alerte sans manuel d'exploitation laisse la personne de garde deviner. Pour chaque alerte critique, écrivez les premières vérifications, les causes courantes et le chemin d'escalade. Pour les partitions sous-répliquées, le manuel d'exploitation pourrait dire : vérifier l'accessibilité du courtier, inspecter l'utilisation du disque, inspecter les erreurs réseau, vérifier les déploiements ou redémarrages récents, identifier les sujets affectés et décider s'il faut suspendre la maintenance.

Pour le retard du consommateur, le manuel d'exploitation pourrait dire : identifier si le retard concerne toutes les partitions ou une seule partition, vérifier la santé du déploiement du consommateur, vérifier les erreurs récentes de l'application, inspecter les dépendances en aval et rechercher les rééquilibrages. Si une seule partition est bloquée, trouver le décalage actuel et inspecter le message en toute sécurité avec des outils internes plutôt que de sauter aveuglément les décalages.

Une bonne surveillance n'élimine pas les incidents. Elle rend les premières décisions plus rapides et moins émotionnelles.

La surveillance de la santé de Kafka fonctionne lorsque chaque métrique est liée à une question opérationnelle. Les partitions sont-elles disponibles ? Les répliques sont-elles à jour ? Les consommateurs suivent-ils le rythme ? Les courtiers manquent-ils de ressources ? Les contrôleurs ou les services de métadonnées sont-ils stables ? Construisez des tableaux de bord et des alertes autour de ces questions, puis maintenez les seuils liés à votre propre charge de travail au lieu des valeurs par défaut de quelqu'un d'autre.