Surveiller Kafka

Ce que vous saurez

• Chaque broker accepte les connexions. Une vérification de port par broker, envoyée depuis l’intérieur de votre réseau par l’agent, ou depuis l’extérieur si le port est ouvert sur Internet.
• Vos consommateurs suivent le rythme. Un script demande à Kafka quel retard accuse un groupe de consommateurs, additionné sur toutes les partitions qu’il lit. Au-delà d’un seuil, c’est un avertissement ; au-delà d’un autre, un problème. Le message indique aussi quand aucun consommateur n’est connecté.

C’est généralement le retard qui compte. Les brokers restent souvent en ligne pendant qu’un consommateur a planté, bloque sur un message défectueux ou tourne au ralenti. Rien ne semble en panne, mais les commandes ne sont plus traitées.

Ce que cette configuration ne peut pas vous dire : si quelque chose est produit. Un topic dans lequel personne n’écrit n’a pas de retard non plus. Si le silence est un problème pour vous, faites en sorte que la tâche du producteur lui-même signale ses exécutions à un battement de cœur.

Avant de commencer

• La machine du broker ajoutée comme hôte dans Gryphon, et l’agent Gryphon installé dessus, ou sur une autre machine du même réseau qui peut joindre les brokers.
• Les outils en ligne de commande de Kafka sur la machine de l’agent, ainsi que le Java dont ils ont besoin. Un broker a déjà les deux. L’exemple suppose que Kafka se trouve dans /opt/kafka.
• Le nom du groupe de consommateurs à surveiller : kafka-consumer-groups.sh --list les affiche.

L’exemple surveille un groupe appelé billing, sur un broker qui écoute sur 127.0.0.1:9092.

Étapes

1Vérifier le port de chaque broker

Ouvrez l’hôte, allez dans Services, choisissez Ajouter le service et sélectionnez Port TCP (agent). Ajoutez-en une par broker. L’agent peut joindre sa propre machine et les adresses privées, alors les adresses des autres brokers fonctionnent aussi.

Si le port des brokers est ouvert sur Internet, Port TCP fait la même chose depuis l’extérieur, sans agent. Cette vérification se connecte à l’hôte auquel elle appartient : elle ne demande donc que le port.

2Activer les vérifications par script

L’agent n’exécute que les programmes d’un dossier que vous désignez, et ce dossier doit appartenir à root sans que personne d’autre puisse y écrire :

sudo install -d -o root -g root -m 0755 /etc/gryphon/scripts

GWC_SCRIPTS_DIR=/etc/gryphon/scripts

sudo systemctl restart gryphon-agent

3Ajouter le script de retard

Enregistrez ceci sous /etc/gryphon/scripts/kafka-lag et rendez-le exécutable avec sudo chmod 755 /etc/gryphon/scripts/kafka-lag. Réglez le groupe et les deux seuils au début du fichier.

#!/bin/sh
# Consumer lag for one Kafka consumer group: messages written to its topics
# that it has not read yet, summed over every partition.
GROUP=billing
WARN=1000
CRIT=10000

export LOG_DIR=/tmp                   # the tools write a log; /tmp is the agent's own
export KAFKA_HEAP_OPTS="-Xmx128m"     # a client, not a broker

out=$(/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server 127.0.0.1:9092 \
    --describe --group "$GROUP" 2>&1) || {
    echo "UNKNOWN: could not describe $GROUP: $(printf '%s' "$out" | tail -n 1)"
    exit 3
}
lag=$(printf '%s\n' "$out" | awk -v g="$GROUP" '$1 == g && $6 ~ /^[0-9]+$/ { sum += $6; n++ } END { if (n) print sum }')
if [ -z "$lag" ]; then
    echo "UNKNOWN: no lag to measure for $GROUP: $(printf '%s' "$out" | tail -n 1)"
    exit 3
fi
idle=""
case "$out" in *"has no active members"*) idle=" (no consumer is connected)" ;; esac

if [ "$lag" -ge "$CRIT" ]; then
    echo "CRITICAL: $GROUP is $lag messages behind$idle"
    exit 2
fi
if [ "$lag" -ge "$WARN" ]; then
    echo "WARNING: $GROUP is $lag messages behind$idle"
    exit 1
fi
echo "OK: $GROUP is $lag messages behind$idle"

Le code de sortie donne l’état : 0 en bon état, 1 avertissement, 2 problème, 3 inconnu. La première ligne affichée est le message que vous verrez dans Gryphon et dans l’alerte. Si le broker ne répond pas, le script indique « inconnu » plutôt que « problème », car les vérifications de port de l’étape 1 couvrent déjà ce cas.

L’agent exécute les scripts sous son propre utilisateur, sans dossier personnel et avec un /tmp privé, et arrête ceux qui durent plus de 10 secondes. Les outils de Kafka démarrent une machine virtuelle Java : ils sont donc plus lents que la plupart des scripts. Exécutez le script comme le fait l’agent, et chronométrez-le :

time sudo systemd-run --pipe --wait -q -p DynamicUser=yes -p PrivateTmp=yes /etc/gryphon/scripts/kafka-lag

Il devrait afficher une ligne et prendre une seconde ou deux. Quelques secondes, c’est correct. S’il approche des 10 secondes, utilisez plutôt la version planifiée décrite sous Variantes.

4Ajouter la vérification par script

Pour un deuxième groupe, copiez le script sous un autre nom, comme kafka-lag-shipping, changez GROUP et ajoutez une autre vérification. Les scripts s’exécutent sans arguments : chaque groupe a donc son propre fichier.

Faire un essai

1. Utilisez Vérifier maintenant sur la ligne de la vérification par script. Son message indique le retard du groupe.
2. Mettez WARN=0 dans le script et vérifiez de nouveau. La vérification passe en avertissement, puisque tout retard atteint ou dépasse maintenant le seuil. Remettez ensuite la valeur d’origine.
3. Arrêtez un consommateur et continuez de produire. Dès que le retard dépasse vos seuils, la vérification suit : avertissement, puis problème, et les alertes partent comme pour toute autre vérification.

Variantes

Une grappe avec SASL ou TLS

Mettez les paramètres du client dans un fichier de propriétés lisible par root seulement, comme /etc/gryphon/kafka.properties, et remettez-le à l’agent sous forme d’identifiant systemd (credential), pour qu’il ne soit pas écrit dans le script :

[Service]
LoadCredential=kafka.properties:/etc/gryphon/kafka.properties

Ajoutez ensuite --command-config "$CREDENTIALS_DIRECTORY/kafka.properties" à la ligne kafka-consumer-groups.sh, puis redémarrez l’agent.

Une machine lente, ou de nombreux groupes

Exécutez plutôt la même vérification à partir de cron, et signalez le résultat à un Battement de cœur. Il n’y a alors aucune limite de 10 secondes, et une seule tâche peut couvrir tous les groupes. Ajoutez un battement de cœur, réglez La tâche s’exécute sur 5 Minutes et le Délai de grâce sur 5 minutes. Puis, dans la crontab d’un utilisateur qui peut exécuter les outils de Kafka :

*/5 * * * * /etc/gryphon/scripts/kafka-lag > /dev/null; if [ $? -lt 2 ]; then curl -fsS -m 10 --retry 3 https://gryphon.gocode.ca/hb/your-token; else curl -fsS -m 10 --retry 3 https://gryphon.gocode.ca/hb/your-token/fail; fi > /dev/null

Un battement de cœur n’a pas d’avertissement : un avertissement est donc signalé ici comme en bon état. Seul un problème, ou une tâche qui ne s’exécute plus du tout, déclenche une alerte.

Dans Docker

Si les brokers sont des conteneurs sur la machine de l’agent, ajoutez aussi une vérification Docker : conteneur pour chacun. Elle repère un conteneur qui a planté ou qui redémarre sans cesse, et lit son healthcheck. Le script de retard a tout de même besoin des outils de Kafka et de Java sur la machine de l’agent elle-même, pointés vers le port que le conteneur publie.