Monitoring on Mook’s Lab Chronicles

De Beszel à Zabbix : pourquoi j’ai refait toute ma supervision

Tue, 15 Sep 2026 22:21:47 +0200

Au départ, je voulais simplement savoir si mes machines allaient bien. Un peu de CPU, de mémoire, de stockage, quelques températures et une alerte quand quelque chose sortait des clous. Beszel répondait très bien à ce besoin.

Son interface était claire, l’installation rapide et, surtout, il était stable. Je pouvais l’ouvrir, prendre la température du homelab en quelques secondes et repartir faire autre chose. Pour un outil de supervision, cette discrétion est une vraie qualité.

Puis mon besoin a évolué en même temps que mon lab. Je ne voulais plus seulement savoir si une VM consommait trop de mémoire. Je voulais savoir si le service qui tournait dessus fonctionnait, si un conteneur avait redémarré, si une sauvegarde était récente, si un mail avait réellement effectué tout son trajet ou encore si les DNS répondaient correctement.

J’ai ajouté Pulse, essayé Checkmk (« bad idea :’) »), multiplié les tests et fini par arriver sur Zabbix. En quelques semaines, j’ai refait presque tout mon système de supervision.

Ce n’est pas l’histoire d’une succession de mauvais outils. C’est plutôt celle d’un besoin qui a grandi vite, porté par la curiosité, jusqu’au moment où maintenir plusieurs réponses partielles est devenu plus pénible que de reprendre le problème depuis le début.

Beszel faisait exactement ce que je lui demandais

J’ai beaucoup aimé Beszel pour sa simplicité et sa légèreté. Il remontait les métriques essentielles de mes machines et de mes conteneurs Docker sans transformer l’installation en projet à part entière. L’interface allait droit au but et je n’avais pas besoin de passer une soirée dans la documentation pour comprendre la mise en place ou l’exploitation.

Ce serait donc injuste de raconter que je l’ai abandonné parce qu’il était instable ou limité dans l’absolu. Il faisait bien son travail. Dans mon périmètre, il ne tenait plus ma cadence insatiable.

Une machine peut avoir 20 % de CPU, beaucoup de mémoire disponible et un disque presque vide tout en rendant un service parfaitement inutilisable. Le processus peut être arrêté. Le certificat peut avoir expiré. Le DNS peut répondre sans fournir la bonne donnée. Un serveur mail peut accepter une connexion SMTP sans être capable de livrer un message jusque dans la boîte de réception.

Je commençais donc à vouloir surveiller ce qui se passait dans les VM, pas seulement autour d’elles.

Pulse apportait de son côté une lecture pertinente de Proxmox et de son environnement. Là encore, le problème n’était pas la qualité des données. Le problème était que je venais d’ajouter un outil supplémentaire à installer, mettre à jour, sauvegarder et comprendre.

J’avais Beszel pour certaines ressources, Pulse pour une autre partie de l’infrastructure, Grafana pour mes dashboards et plusieurs sondes qui vivaient encore ailleurs. Chaque écran avait une raison d’exister. Leur addition commençait pourtant à raconter une histoire assez différente : pour comprendre un incident, il fallait déjà savoir quel outil ouvrir.

La friction qui a lancé la suite est venue de là. Je ne cherchais pas à collectionner les dashboards. Je voulais réduire le nombre de systèmes capables de décider qu’il y avait un problème.

Checkmk m’a montré ce qui me manquait

Je n’avais encore jamais vraiment utilisé Checkmk. C’était donc l’occasion de tester une solution plus large (et probablement sur-vendue), capable de découvrir une machine et de transformer automatiquement ce qu’elle expose en services supervisés.

La première impression a été plutôt bonne. L’agent et les modules fournis de base remontaient beaucoup de choses sans que j’aie à tout construire à la main. CPU, mémoire, disques, interfaces, services systemd, conteneurs Docker : je retrouvais enfin les ressources et les services dans la même plateforme.

C’est cette profondeur prête à l’emploi qui m’a convaincu : je pouvais partir d’une VM, descendre jusqu’à ses services et ajouter mes propres contrôles lorsque le standard ne suffisait plus.

J’ai ainsi intégré des sondes DNS, des contrôles Proxmox et plusieurs scénarios mail. Je ne voulais pas seulement vérifier que les ports 25 ou 993 étaient ouverts. Je voulais établir une session chiffrée, m’authentifier, envoyer un message identifié, le retrouver en IMAP, mesurer son délai et nettoyer la boîte après le test.

À ce moment-là, ma supervision commençait réellement à représenter le fonctionnement du homelab.

Elle a aussi commencé à faire du bruit. Les interfaces TAP éphémères de Proxmox disparaissaient, les jobs du runner provoquaient des pics de mémoire et certains seuils réagissaient à des variations sans conséquence. J’ai raconté séparément comment j’ai repris en main ces alertes Checkmk, car cette étape m’a appris une chose importante : collecter beaucoup d’informations ne suffit pas, il faut encore décider lesquelles méritent de m’interrompre.

Puis l’outil a commencé à me fatiguer

Plus je poussais Checkmk, plus son ergonomie me ralentissait. L’interface me donnait parfois l’impression d’avoir été dessinée par un maçon : tout était solide, mais il fallait connaître le plan du bâtiment pour retrouver la bonne porte.

La création de dashboards a été le point le plus visible. J’avais déjà Grafana, où je pouvais construire une vue exactement comme je l’imaginais. Dans Checkmk, obtenir une présentation sur mesure me demandait beaucoup plus d’efforts pour un résultat qui me convenait moins.

La performance a aussi pesé dans la balance. Sur ma VM équipée de quatre vCPU, l’expérience restait plus lourde que ce que j’attendais pour la taille de mon homelab. Les métriques étaient bien conservées, mais leur consultation et leur chargement me semblaient lents. Dans mon usage, les contrôles restaient essentiellement calés sur la cadence standard d’une minute, alors que j’avais déjà une collecte plus fine dans VictoriaMetrics pour alimenter Grafana.

Une partie de cette différence vient du découpage des éditions. Checkmk Community est bien entièrement open source, mais elle utilise le cœur Nagios. Le Checkmk Micro Core, plus efficace, ainsi que plusieurs fonctions avancées de graphes et de connexion aux bases de métriques externes appartiennent aux éditions commerciales.

Le SSO (Single Sign-On) a fini d’illustrer ce décalage. L’intégration SAML native est elle aussi commerciale. En Community, j’aurais dû ajouter une couche d’authentification Apache ou monter une intégration LDAP avec Authentik uniquement pour Checkmk.

Ce n’était pas impossible. C’était juste franchement pénible, en 2026, de réserver une simple connexion SSO aux versions payantes. Pour les ACL ou le RBAC, à la limite… mais la connexion ?

Je n’ai rien contre les logiciels payants. Je préfère même une proposition claire, gratuite ou payante, à une succession de limites qui apparaissent lorsque je commence à exploiter sérieusement l’outil. Avec Checkmk, j’avais choisi Community pour sa promesse open source, mais plusieurs améliorations qui répondaient précisément à mes frustrations me renvoyaient vers une autre édition.

J’ai donc profité de ce moment pour vérifier si un autre outil correspondait mieux à la direction prise par mon homelab.

Revenir à Zabbix, mais pas par nostalgie

Zabbix n’était pas une découverte totale. Je l’avais déjà utilisé auparavant pour du pro et je connaissais une partie de ses forces : une grosse communauté, beaucoup de modèles, une architecture éprouvée et une grande liberté pour construire des contrôles sur mesure.

Son Agent 2 a beaucoup compté dans mon choix. Il reprend les contrôles système classiques et ajoute une architecture de plugins pour des composants comme Docker, systemd, SMART ou différentes bases de données. Son empreinte restait raisonnable pour mes machines, surtout face à l’alternative qui consistait à multiplier les agents spécialisés.

Surtout, Zabbix me laissait plusieurs chemins pour une même donnée : agent actif, requête HTTP, SNMP, élément dépendant, découverte bas niveau, script externe ou UserParameter. Cette variété peut rendre la prise en main dense, mais elle correspond bien à ma manière de travailler. Si un contrôle n’existe pas, je peux le construire, le versionner et le rattacher au même hôte que le reste de sa supervision.

La plateforme reste open source sous licence AGPL. Je pouvais utiliser le SSO SAML, ajuster la rétention et créer mes modèles sans changer d’édition. Grafana gardait son rôle de cockpit : VictoriaMetrics alimentait les vues d’infrastructure, et Zabbix Agent 2 lui fournissait les métriques des conteneurs sans ajouter cAdvisor.

Sur le papier, le choix était séduisant. Il restait à prouver que Zabbix pouvait reprendre les contrôles qui rendaient Checkmk réellement utile chez moi.

Une migration en parallèle

J’ai fait fonctionner Zabbix et Checkmk en parallèle le temps de reprendre les contrôles indispensables : Proxmox, Docker, systemd, OPNsense, DNS et les boucles mail. Une fois la couverture et les notifications vérifiées, Zabbix est devenu la plateforme de référence le 13 août 2026 et les agents Checkmk ont été retirés progressivement. J’ai conservé une sauvegarde protégée de la VM Checkmk pour pouvoir revenir en arrière si nécessaire.

Ce que cette migration a réellement changé

Aujourd’hui, je n’attends pas d’un seul outil qu’il fasse tout.

Grafana reste mon premier écran lorsque je veux prendre la température du homelab. Ses dashboards sont directs, visuels et construits autour de mes questions. Zabbix collecte les états, découvre les services et décide quand une anomalie devient un problème. Argus récupère dans Zabbix les versions réellement déployées. Plus récemment, CairnOps est venu ajouter une couche d’hypervision en utilisant Zabbix comme source.

Je sais désormais où regarder une tendance, où chercher un événement et quel système porte la décision d’alerter. Ajouter un outil reste possible, mais seulement s’il possède un rôle qui n’existe pas déjà ailleurs.

Beszel m’a rappelé la valeur d’une supervision simple. Checkmk m’a montré l’intérêt de descendre jusqu’aux services et aux contrôles métier. Zabbix m’a finalement donné la souplesse nécessaire pour réunir ces besoins sans abandonner les outils spécialisés qui fonctionnaient déjà bien.

Dans les prochains articles, je ferai le tour de cette architecture actuelle : Grafana comme cockpit, Zabbix derrière les alertes, puis les outils qui gravitent autour, notamment Argus, Uptime Kuma, LogChef et PatchMon. CairnOps aura droit à son propre récit, parce que son arrivée commence déjà à changer ma manière de lire l’état global du homelab.

Trop d’alertes, plus aucune confiance : comment j’ai repris en main Checkmk

Wed, 29 Jul 2026 16:00:00 +0200

Une interface réseau disparaît à la fin d’un job. La mémoire du runner grimpe pendant un build. Une sonde mail dépasse son délai une seule fois. Un disque rappelle toutes les quelques minutes qu’il est toujours plein.

Pris séparément, chacun de ces événements mérite d’être observé. Transformés avec la même urgence en notifications, ils finissent surtout par m’apprendre à ne plus les regarder.

C’est le piège classique de la supervision : au début, on veut tout voir. Puis on ajoute des contrôles, des machines et des seuils jusqu’au moment où le système fonctionne techniquement, mais où le signal utile se retrouve noyé dans le bruit.

J’ai donc repris mes règles Checkmk une par une. Mon objectif n’était pas d’obtenir un joli écran entièrement vert. Je voulais qu’une notification signifie de nouveau : « il faut regarder maintenant ».

Le bruit n’a pas une cause unique

La mauvaise solution aurait été de relever tous les seuils ou de désactiver les services pénibles. C’est tentant, rapide et particulièrement efficace pour fabriquer une fausse tranquillité.

À la place, j’ai classé chaque alerte dans l’une de ces familles :

Situation	Exemple dans mon homelab	Réponse
état attendu	interface TAP supprimée avec une VM éphémère	ignorer précisément ce service
incident transitoire	pic de mémoire pendant un job CI	demander une seconde confirmation
problème réel mais répétitif	disque toujours en alerte	conserver l’état, espacer les notifications
seuil mal adapté	résolution DNS correcte mais un peu variable	recalibrer avec une mesure cohérente

Cette distinction paraît évidente après coup. Dans la pratique, elle oblige à répondre à une question parfois inconfortable : qu’est-ce qui justifie réellement de m’interrompre ?

Les interfaces TAP : du bruit parfaitement normal

Mes nœuds Proxmox créent des interfaces TAP pour connecter les interfaces réseau virtuelles des VM. Leur nom suit une forme comme :

1

tap<vmid>i<nic>

Ces interfaces vivent aussi longtemps que la VM ou la charge CI correspondante. Lorsqu’une machine temporaire s’arrête, son interface disparaît. Checkmk peut alors interpréter cette disparition comme un changement d’état à signaler.

Le problème ne venait donc pas d’une panne réseau. Le cycle de vie normal d’une ressource éphémère était traité comme celui d’un port physique.

J’ai commencé par faire découvrir les interfaces Proxmox avec leur description Linux stable plutôt qu’avec un numéro générique du type Interface 12. Cela évite qu’un bridge, un VLAN ou une nouvelle interface récupère le service d’un ancien périphérique.

J’ai ensuite ajouté une règle très ciblée :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "ruleset": "ignored_services",
 "description": "Homeblack - ignore ephemeral Proxmox TAP interfaces",
 "value": True,
 "conditions": {
 "host_name": {
 "match_on": ["pve-dell", "pve-forum", "pve-fuji"],
 "operator": "one_of",
 },
 "service_description": {
 "match_on": [r"Interface tap[0-9]+i[0-9]+$"],
 "operator": "one_of",
 },
 },
}

Je n’ignore pas « les interfaces de Proxmox ». Je retire uniquement les services qui correspondent au motif des TAP éphémères. Les interfaces physiques, les bridges, les VLANs et les interfaces des machines invitées restent surveillés.

C’est une nuance importante : une bonne exception décrit un comportement attendu, pas une catégorie suffisamment large pour faire disparaître le problème.

Un pic n’est pas encore une panne

Le runner GitLab présente un autre cas. Pendant un build, sa consommation mémoire peut monter brutalement pendant un cycle de contrôle, puis revenir à la normale.

Ce pic reste intéressant. S’il dure, je veux le savoir. S’il ne concerne qu’une mesure isolée, je ne veux pas être interrompu.

Checkmk distingue justement les états soft et hard. Un premier échec peut rester transitoire ; il ne devient un problème confirmé qu’après le nombre de tentatives défini.

Pour le service Memory de trust-runner-01, j’ai choisi deux contrôles consécutifs :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "ruleset": "extra_service_conf:max_check_attempts",
 "description": "Homeblack - retry transient runner memory pressure",
 "value": 2,
 "conditions": {
 "host_name": {
 "match_on": ["trust-runner-01"],
 "operator": "one_of",
 },
 "service_description": {
 "match_on": [r"Memory$"],
 "operator": "one_of",
 },
 },
}

Un pic d’un cycle reste visible dans l’historique, mais ne déclenche pas de notification immédiate. Si la pression persiste au contrôle suivant, l’état devient hard et l’alerte suit son chemin normal. Avec la fréquence actuelle des contrôles, cela représente environ une minute de confirmation.

Les pics courts restent visibles dans le graphe sans transformer automatiquement chaque mesure isolée en notification.

J’ai appliqué le même raisonnement aux contrôles SMTP entrant et IMAP de ma plateforme mail. Un timeout isolé mérite une nouvelle tentative ; deux échecs consécutifs commencent à ressembler à un incident.

En revanche, je n’ai pas ajouté un délai arbitraire de plusieurs heures au test de livraison de bout en bout. Cette sonde possède déjà sa propre notion du temps : avertissement après 120 secondes et état critique après 300 secondes. Ajouter quatre heures de silence par-dessus revenait à rendre le contrôle presque inutile.

Espacer une notification sans effacer le problème

Les disques posent une question différente. Un filesystem plein, une erreur SMART ou une latence d’entrée-sortie ne disparaissent pas parce que j’ai déjà reçu l’alerte.

Mais recevoir continuellement le même message ne rend pas la réparation plus rapide.

J’ai conservé les services SMART, Filesystem et Disk IO visibles dans Checkmk avec leurs états normaux. C’est uniquement la fréquence de leurs notifications sortantes qui est limitée :

1
2


DISK_NOTIFICATION_COOLDOWN_SECONDS = 24 * 60 * 60
DISK_SERVICE_PREFIXES = ("SMART ", "Filesystem ", "Disk IO ")

Le mécanisme garde une réservation par couple hôte/service. Une première notification de problème passe, puis les répétitions sont bloquées pendant 24 heures glissantes. Si le problème reste actif, Checkmk envoie un rappel quotidien.

Les retours à l’état normal restent présents dans l’historique Checkmk, mais ne génèrent pas de nouvelle notification pour ces trois familles de services. Je préfère ouvrir l’interface et retrouver toute la chronologie plutôt que d’être interrompu à chaque oscillation autour d’un seuil disque.

Il y a un détail auquel je tenais : si l’envoi de la notification échoue, la réservation est libérée. Le système pourra donc retenter plus tard au lieu de considérer comme livré un message qui n’est jamais arrivé.

Enfin, cette limitation ne concerne ni les hôtes, ni les autres services. Une machine inaccessible ou un contrôle métier en échec ne profite pas discrètement du même silence.

Un seuil doit représenter un risque

La supervision DNS de Technitium m’a fourni un bon exemple de seuil techniquement valide, mais opérationnellement trop sensible.

Je contrôle deux choses depuis le serveur Checkmk :

une résolution DNS autoritative en UDP, avec vérification de la réponse ;
l’ouverture du transport DNS sur le port TCP 53.

Au départ, les deux contrôles avertissaient au-dessus de 500 millisecondes. J’ai conservé ce seuil pour l’ouverture TCP, mais porté l’avertissement UDP à une seconde. L’état critique reste fixé à 1,5 seconde et le timeout à trois secondes.

Pourquoi séparer les deux ? Une connexion TCP sur le réseau interne doit rester très rapide. Une requête DNS complète traverse davantage d’étapes et peut subir une variation ponctuelle sans que le service soit dégradé.

Le 29 juillet 2026, ma vérification en lecture seule remontait :

Service	État observé	Temps de réponse
résolution DNS Technitium en UDP	OK	65 ms
transport DNS Technitium en TCP	OK	7 ms

Ce sont des mesures prises à un instant donné, pas une promesse de performance. Elles confirment surtout que les contrôles interrogent réellement le service et exposent leur métrique après la modification.

La mesure UDP reste très en dessous du seuil d’avertissement fixé à une seconde ; le seuil critique apparaît à 1,5 seconde.

Ce que je refuse de faire taire

Réduire le bruit n’a d’intérêt que si les vrais problèmes restent bruyants.

Les avertissements critiques NVMe et les erreurs d’intégrité continuent donc d’alerter dès leur première occurrence. Les filesystems restent surveillés avec leurs seuils normaux. Lorsque le disque du runner manque réellement de place, la réponse attendue est un nettoyage ou une augmentation du volume, pas un seuil plus généreux.

Même logique pour les TAP : j’ignore les interfaces éphémères, mais pas les uplinks. Pour la mémoire du runner, j’ajoute une confirmation, mais je ne supprime pas le contrôle. Pour le DNS, je détends seulement le seuil UDP ; le contrôle TCP conserve sa valeur plus stricte.

Je me sers désormais de cette règle simple :

Si l’alerte représente un problème mesuré, je la garde. Si elle décrit un comportement attendu, je corrige son modèle.

Des règles versionnées plutôt que des clics oubliés

Tous ces réglages sont décrits dans le dépôt d’infrastructure et appliqués par un helper qui utilise l’API REST de Checkmk. Cela me permet de relire une exception, de comprendre pourquoi elle existe et de la tester comme le reste du code.

Pour appliquer les règles de calibration :

1

python3 ansible/scripts/checkmk-rest-api.py calibrate-rules

Je rejoue ensuite la commande sans activation :

1

python3 ansible/scripts/checkmk-rest-api.py calibrate-rules --no-activate

La seconde exécution doit annoncer toutes les règles gérées comme inchangées. Pour les modifications de découverte, notamment les interfaces Proxmox, je relance aussi explicitement la découverte des services concernés :

1
2
3
4


python3 ansible/scripts/checkmk-rest-api.py discover \
 --host pve-dell \
 --host pve-forum \
 --host pve-fuji

Les tests automatisés vérifient également la portée des règles : motif exact des TAP, deux tentatives pour la mémoire du runner et intervalle de 1 440 minutes pour les problèmes disque persistants.

Enfin, je contrôle l’état effectif avec Livestatus, directement sur le serveur Checkmk. Lors de la dernière vérification, le service Memory du runner était bien configuré avec deux tentatives maximales. Les deux boucles mail et les contrôles DNS étaient en état OK.

Cette dernière étape est indispensable. Une configuration correcte dans Git ne prouve pas encore que Checkmk l’a activée ni qu’elle s’applique au bon service.

Ce que je retiens

Je pensais au départ qu’une bonne supervision devait tout remonter le plus vite possible. Je la vois maintenant comme un système de décisions : que faut-il conserver dans l’historique, que faut-il confirmer et qu’est-ce qui mérite réellement une interruption ?

Les quatre leviers ne sont pas interchangeables :

ignorer précisément une ressource éphémère ;
confirmer un état transitoire avec une nouvelle tentative ;
espacer le rappel d’un problème déjà connu ;
adapter un seuil à la mesure réellement effectuée.

Je garde volontairement le canal de réception en dehors de cet article. Je raconterai prochainement comment j’achemine ces alertes, où je les reçois et comment je décide lesquelles ont réellement le droit de m’interrompre.

Depuis cette reprise, l’écran vert m’intéresse moins. Ce qui compte, c’est que la prochaine notification inhabituelle récupère immédiatement mon attention — et qu’elle la mérite.