Zabbix : à quoi ça sert, et comment bien s'en servir ?

Le disque d'un serveur de base de données s'est rempli un samedi soir. Les sauvegardes ont échoué, puis l'application. Lundi matin, ce sont les clients qui ont prévenu. La métrique existait, personne ne la regardait. C'est exactement le problème que règle un outil de supervision.

Zabbix est une plateforme de supervision open source qui collecte des métriques sur des serveurs, des équipements réseau, des bases de données, des applications et des sites web, détecte les problèmes et envoie les alertes. Créé en 2001 par Alexei Vladishev et développé aujourd'hui par la société lettone Zabbix SIA, il est publié sous licence AGPLv3 depuis la version 7.0. Le code source est sur GitHub : zabbix/zabbix.

Le dépôt GitHub est un miroir : les tickets et le développement passent par l'outil de suivi de Zabbix, d'où son compteur d'issues à zéro et ses 6 500 étoiles, modestes pour un projet de cette taille. Zabbix est surtout connu en entreprise, chez les hébergeurs, les opérateurs et les services informatiques.

À quoi sert Zabbix

Zabbix répond à une question : est-ce que tout fonctionne, et sinon, qu'est-ce qui casse ? Pour y répondre, il couvre toute la chaîne avec un seul outil.

Concrètement, une installation Zabbix supervise le CPU, la mémoire et les disques de chaque serveur, les ports et le trafic de chaque switch, la réplication PostgreSQL, l'état des conteneurs Docker, le temps de réponse d'un parcours de connexion sur un site, la date d'expiration des certificats TLS. Le tout configuré depuis une interface web, sans fichier à maintenir.

Comment il fonctionne

Quatre composants suffisent. Le Zabbix server reçoit les valeurs, évalue les triggers et déclenche les alertes. La base de données stocke la configuration et tout l'historique. Le frontend PHP sert l'interface web. L'agent, installé sur chaque machine, collecte les métriques locales.

L'agent peut être interrogé par le serveur sur le port 10050 (checks passifs), ou récupérer lui-même la liste de ses métriques et pousser les valeurs vers le port 10051 du serveur (checks actifs). Le mode actif ne demande aucun port ouvert sur les machines supervisées, ce qui le rend plus simple derrière un NAT et plus sûr. Si vous ouvrez le 10050, limitez-le à l'adresse du serveur avec une règle comme celles du guide UFW.

Pour un site distant, un proxy collecte localement et transmet au serveur central par une seule connexion sortante. Si le lien coupe, il garde les données en mémoire tampon et les renvoie au retour.

La pièce centrale, c'est le template. Un hôte lié au template « Linux by Zabbix agent active » reçoit d'un coup une centaine de métriques, une trentaine de triggers aux seuils raisonnables, des graphiques et la découverte automatique des disques et des interfaces. Zabbix 7.0 livre plusieurs centaines de templates : PostgreSQL, Nginx, Docker, Cisco, Juniper, MikroTik, VMware, Proxmox, et bien d'autres.

Zabbix, Prometheus ou Uptime Kuma ?

Zabbix n'est pas toujours le bon choix. Voici comment je tranche.

Prometheus est pensé pour des cibles éphémères qui exposent leurs propres métriques, et brille dans Kubernetes. Le duo Grafana et Prometheus y est plus naturel que Zabbix. Uptime Kuma fait une seule chose, vérifier qu'un service répond, et la fait en cinq minutes d'installation.

Zabbix gagne dès que le parc est hétérogène : des serveurs Linux et Windows, des switches, un pare-feu, des bases de données, un vieux NAS. Un seul outil, une seule logique d'alerte, une seule base. Les trois cohabitent d'ailleurs très bien : Grafana sait afficher les données de Zabbix, et Uptime Kuma peut surveiller le frontend de Zabbix depuis une autre machine.

Les bonnes pratiques qui changent tout

Installer Zabbix prend une heure. Le rendre utile prend plus longtemps. La plupart des installations ratées le sont pour les mêmes raisons.

Ne jamais modifier un template officiel

Les templates officiels sont mis à jour à chaque version. Changer un seuil directement dedans, c'est perdre la modification à la prochaine importation. Leurs seuils lisent des macros, comme {$CPU.UTIL.CRIT} ou {$VFS.FS.PUSED.MAX.CRIT}, qu'on surcharge au niveau d'un hôte ou d'un groupe. Une macro peut même prendre un contexte : 90 % pour tous les disques, 95 % pour la partition de la base de données.

Préférer l'agent 2 en mode actif

L'agent 2, écrit en Go, a remplacé l'agent historique en C pour presque tous les usages. Il embarque des plugins pour Docker, PostgreSQL, MySQL, Redis et les certificats TLS. En mode actif, combiné à l'enregistrement automatique, ajouter un serveur se résume à installer l'agent avec les bonnes métadonnées : Zabbix le crée, le range dans le bon groupe et lui applique les bons templates.

Mesurer sur une durée, pas sur une valeur

Un trigger last(/web-01/system.cpu.util)>90 sonne à chaque pic de vingt secondes. min(/web-01/system.cpu.util,10m)>90 ne sonne que si la charge reste au-dessus du seuil pendant dix minutes. Ajoutez une hystérésis, ouverture à 90 %, fermeture sous 85 %, et un disque qui oscille autour du seuil n'ouvrira plus un problème toutes les cinq minutes.

Déclarer les dépendances

Un switch tombe, vingt serveurs deviennent injoignables : sans dépendances, vingt et une alertes. Avec une dépendance de chaque trigger « serveur injoignable » vers « switch injoignable », une seule. C'est le réglage le plus rentable contre le bruit.

Router les alertes par sévérité et par tag

Seuls les problèmes High et Disaster doivent réveiller quelqu'un. Les autres vont dans un tableau de bord ou un canal lu en journée. Les tags, comme service:facturation ou équipe:base-de-données, routent ensuite chaque problème vers la bonne équipe sans maintenir de listes d'hôtes. Pour les notifications sur téléphone, un webhook de quelques lignes vers ntfy suffit.

La règle que j'applique : chaque alerte doit appeler une action. Si la réponse à une alerte est « ah oui, c'est normal », le trigger est faux.

Régler la base de données dès le premier jour

C'est la base qui limite Zabbix en premier. 10 000 métriques collectées chaque minute, c'est plus de 14 millions de lignes par jour. Deux réglages évitent la catastrophe : un historique brut court (7 à 30 jours) et des tendances horaires longues (un à deux ans), imposés globalement dans le housekeeping. Sur PostgreSQL, l'extension TimescaleDB compresse l'historique et rend sa purge instantanée. Au-delà de quelques milliers d'hôtes, elle devient indispensable.

Superviser le superviseur

Si le serveur Zabbix tombe, plus aucune alerte ne part, et personne ne le sait. Zabbix intègre depuis la version 6.0 un mode cluster : plusieurs serveurs sur la même base, un seul actif, bascule automatique. À défaut, un check externe sur une autre machine vérifie au moins que le frontend répond.

Sécuriser l'accès

Le mot de passe par défaut d'Admin est zabbix, et il faut le changer à la première connexion. Chiffrez les échanges avec les agents par une clé PSK propre à chaque hôte. Activez l'authentification multifacteur, arrivée avec la 7.0. Et n'exposez jamais le frontend sur Internet sans VPN devant : il donne la carte complète de votre infrastructure.

Quelle version installer

Zabbix publie une version LTS tous les 18 mois environ, supportée cinq ans, et des versions standard tous les six mois, supportées un an. Début novembre 2026, la 7.0 LTS (juin 2024) est supportée jusqu'en juin 2027 pour les correctifs et juin 2029 pour les failles critiques. La 7.4 est la dernière version standard. La 8.0 LTS est en release candidate et attendue pour la fin de l'année.

Pour une installation de production aujourd'hui, je choisis la 7.0 LTS, et je migrerai vers la 8.0 LTS quand elle aura reçu quelques versions correctives. Les montées de version de Zabbix se passent bien, à une condition : les tester sur une copie de la base de production, car la migration d'une grosse base peut prendre des heures.

Ses limites

Zabbix a des défauts. Toute la configuration vit dans l'interface et dans la base, ce qui complique le versionnement : l'export des templates en YAML et l'API compensent, sans égaler un fichier de configuration dans Git. La courbe d'apprentissage est réelle, avec un vocabulaire propre (items, triggers, actions, media types) et des réglages éparpillés dans l'interface. Et pour des conteneurs qui vivent quelques minutes, son modèle centré sur l'hôte est moins naturel que celui de Prometheus.

Pour aller plus loin que cet aperçu, la formation Supervision avec Zabbix reprend tout pas à pas : installation avec PostgreSQL et Nginx ou Docker Compose, agent 2 et templates, triggers et découverte automatique, alertes et escalades, SNMP et proxies, API, haute disponibilité et mise en production.

Zabbix n'est pas l'outil le plus moderne du paysage, et c'est sa force : vingt ans de templates, un SNMP natif, des alertes intégrées, un historique long sans brique supplémentaire. Ce qui fait la différence entre une installation utile et un tableau de bord rouge que plus personne ne regarde, ce n'est pas l'outil, c'est la discipline sur les alertes. Commencez par peu de triggers, bien réglés, et n'ajoutez une alerte que si quelqu'un sait quoi faire quand elle sonne.