J’ai fait de la prod tout ma carrière, et l’observability est un sujet qui me passionne. Mais dans le monde du monitoring, un sujet en apparence simple est en fait toujours pénible: le blackbox monitoring.

Lorsqu’on déploie des services ou de l’infrastructure, on veut généralement exécuter des health checks dessus, de différents types. Par exemple:

En cas de problèmes, on veut être alerté. On veut aussi pouvoir facilement configure le health check à exécuter. Dans le cas d’une requête HTTP, on veut pouvoir choisir la méthode HTTP, le path, passer des paramètres, des headers, changer le code retour attendu…​

Il y a plus de 4 ans j’étais ultra saoulé par blackbox exporter et donc j’ai écrit Cabourotte.

C’était à la base un simple binaire Go qui exécute des health checks définis dans un fichier de configuration périodiquement. Il peut toujours s’utiliser comme cela aujourd’hui, comme expliqué dans sa doc.

demo

Voici un exemple de configuration Cabourotte avec un check HTTP et un TCP:

Si vous installez Cabourotte, vous pouvez le lancer avec cabourotte daemon --config ~/.cabourotte.yaml --debug: il va démarrer et commencer à exécuter les health checks:

Cabourotte expose les métriques des health checks au format Prometheus sur /metrics:

Avec cela (bucket + counter Prometheus), il est facile de configurer des règles d’alerting quelle que soit votre stack d’observability: tous les outils (propriétaires comme open source) comprennent le format Prometheus, donc ils peuvent tous ingérer ces métriques et vous pourrez définir des règles d’alerte sur le temps d’exécution des checks ou leurs status (success ou failure). Pareil pour les dashboards.

Je le répète: je pense que les bons outils ne sont pas les outils "clés en main" mais qui s’insèrent dans l’écosystème observability. Je ne suis pas intéressé par avoir 2 outils de dashboard, ou 2 outils d’alerting: je veux des standards.

Cabourotte supporte des tonnes d’options pour les checks (voir la doc pour la liste) et 5 types de checks (TCP, HTTP, DNS, TLS, commandes shell arbitraires).

Il génère des logs en JSON, facilement consommables, supporte le hot reload sur SIGHUP, permet de pousser si besoin les résultats des checks dans des systèmes externes, via HTTP par exemple, dispose d’une API, et même d’une UI basique degueulasse pour récupérer l’état courant des checks:

On peut même exécuter des health checks one-off avec via l’API: ce check ne va pas s’exécuter périodiquement mais s’exécutera immédiatement et vous retournera le résultat: pratique pour lancer vite fait quelques tests sur un endpoint encore non configuré.

Et on peut très bien utiliser Cabourotte comme cela: vous déployez le binaire sur un ou des serveurs, vous le configurez via fichier de configuration ou API, vous consommez ses métriques et voilà. Ca marche très bien.

Mais je voulais aller plus loin. C’est bien beau le fichier de configuration pour configurer les checks mais moi j’ai dizaines voir des centaines d’endpoints à monitorer, ultra dynamiques, je veux plusieurs Point of Presence pour mes checks…​ bref faut passer l’outil au niveau supérieur. Appclacks server est né.

Appclacks server, c’est une API HTTP avec une base de données PostgreSQL qui fournit des produits liés au monitoring. Une des fonctionnalités est de configurer les health checks pour Cabourotte.

Au lieu de créer les health checks dans Cabourotte via le fichier de configuration ou l’API, vous les créez dans Appclacks.

Il est ensuite possible de configurer Cabourotte pour venir périodiquement chercher sa configuration en tapant l’API d’Appclacks.

demo

Suivez la doc pour démarrer Appclacks + Cabourotte en local via docker compose:

Vous avez donc maintenant en local

Ici, la configuration de Cabourotte contient seulement ceci:

Toutes les 10 secondes, Cabourotte viendra chercher les health checks configurés dans Appclacks en tapant localhost:9000/api/v1/cabourotte/discovery et mettra sa configuration à jour. Les health checks s’exécuteront ensuite de la même façon que via le fichier de configuration.

Pourquoi c’est intéressant ? Car vous gérez tous vos définitions de health checks de manière centralisée. Vous pouvez déployer 1, 2, 3, 10…​ instances de Cabourotte à travers le monde et elles viendront toutes chercher leurs configurations régulièrement en tapant l’API d’Appclacks (qui supporte du Basic Auth et mTLS d’ailleurs si besoin).
On peut même sélectionner quelles health checks exécuter dans cabourotte via des labels. Par exemple passer dans l’option query.labels de la partie discovery environment=production,team=sre ferait que cette instance de Cabourotte n’exécuterait que les health checks configurés avec ces labels dans Appclacks (voir doc).

J’ai fait un énorme effort sur le tooling d’Appclacks pour gérer les health checks:

Il y en a pour tout les goûts.

Résultat ? On a un outil:

Appclacks fournit aussi d’autres outils liés à l’observability que je présenterai dans d’autres articles prochainement.
Mais je pense qu’aujourd’hui, sur la partie health check, c’est déjà un très bon outil qui je l’espère trouvera sa place.

N’hésitez pas à l’essayer et à me faire des retours. J’ai pas voulu surcharger l’article, suivez la doc pour des exemples ;)