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.