Superviser serveurs, réseau, bases de données et sites web avec Zabbix 7.0 LTS : installation, agent 2, templates, triggers, alertes, SNMP, proxies, API et mise en production.
Superviser, c'est répondre à une question avant qu'un utilisateur ne la pose : est-ce que tout fonctionne, et sinon, qu'est-ce qui casse ? Un serveur qui répond au ping peut avoir un disque plein. Un site qui s'affiche peut avoir un certificat qui expire dans trois jours. La supervision mesure en continu ce qui compte, compare à des seuils, et prévient quelqu'un quand un seuil est franchi.
Zabbix est une plateforme de supervision open source créée en 2001 par Alexei Vladishev, aujourd'hui développée par la société Zabbix SIA en Lettonie. Elle collecte des métriques sur des serveurs, des équipements réseau, des bases de données, des applications et des services cloud, les stocke dans une base SQL, détecte les problèmes et envoie les alertes. Depuis la version 7.0, elle est publiée sous licence AGPLv3. Le code source est sur GitHub : zabbix/zabbix.
Zabbix couvre toute la chaîne, ce qui le distingue d'outils plus spécialisés :
Tout se configure depuis une interface web, sans fichier YAML à maintenir. C'est un choix assumé, avec ses avantages et ses limites, qu'on retrouvera tout au long du cours.
| Composant | Rôle | Port |
|---|---|---|
| Zabbix server | Le cœur : reçoit les données, évalue les triggers, déclenche les actions | 10051 |
| Base de données | PostgreSQL ou MySQL/MariaDB : configuration, historique, tendances, événements | 5432 / 3306 |
| Frontend web | Interface PHP pour configurer et consulter | 80 / 443 |
| Agent / Agent 2 | Installé sur chaque machine supervisée, collecte les métriques locales | 10050 |
| Proxy | Collecte pour le compte du serveur sur un site distant, puis lui transmet | 10051 |
| Java gateway | Interroge les applications Java par JMX | 10052 |
| Web service | Génère les rapports PDF planifiés | 10053 |
Seuls les quatre premiers sont indispensables. Le serveur, la base et le frontend tiennent sans problème sur une seule machine pour quelques centaines d'hôtes.
Le chemin d'une donnée est simple. L'agent mesure l'espace disque sur un serveur web et envoie la valeur au Zabbix server. Le serveur l'écrit en base, réévalue les triggers qui en dépendent, et si l'un d'eux passe en état « problème », il exécute les actions prévues. Le frontend lit la même base pour afficher graphiques et problèmes.
L'agent Zabbix fonctionne de deux façons, et le choix a des conséquences sur le réseau.
| Mode | Qui ouvre la connexion | Port à ouvrir | Quand l'utiliser |
|---|---|---|---|
| Passif | Le serveur interroge l'agent | 10050 entrant sur l'hôte supervisé | Réseau local, peu d'hôtes |
| Actif | L'agent récupère sa liste de métriques et pousse les valeurs | 10051 entrant sur le serveur | Hôtes derrière un NAT, gros volumes, surveillance de logs |
En mode actif, c'est l'agent qui fait le travail de planification. Le serveur est soulagé, et il n'y a aucun port à ouvrir sur les machines supervisées. C'est le mode que je recommande par défaut. La surveillance de fichiers de logs ne fonctionne d'ailleurs qu'en mode actif.
Zabbix a son propre vocabulaire. Il vaut mieux l'avoir en tête dès le départ, car l'interface l'utilise partout.
| Terme | Ce que c'est |
|---|---|
| Host | Une entité supervisée : serveur, switch, site web, base de données |
| Host group | Un regroupement d'hôtes, utilisé pour les droits et les filtres |
| Item | Une métrique collectée : system.cpu.util, vfs.fs.size[/,pused] |
| Trigger | Une expression sur un ou plusieurs items, qui définit un problème |
| Problem / Event | L'état d'un trigger en défaut, et l'historique de ses changements |
| Template | Un ensemble réutilisable d'items, triggers, graphiques et règles de découverte |
| Low-level discovery (LLD) | La découverte automatique des disques, interfaces, services d'un hôte |
| Action | Ce qui se passe quand un problème apparaît : notifier, exécuter une commande |
| Media type | Le canal d'envoi : e-mail, Slack, Telegram, webhook |
| Macro | Une variable, comme {$CPU.UTIL.CRIT} ou {HOST.NAME} |
Le template est la pièce maîtresse. On ne configure presque jamais un item à la main sur un hôte : on lie l'hôte à un template, et il hérite de toute la supervision d'un coup.
Zabbix n'est pas le seul outil de supervision open source, et il n'est pas toujours le bon choix.
| Critère | Zabbix | Prometheus + Grafana | Uptime Kuma |
|---|---|---|---|
| Modèle | Agent, SNMP, HTTP, configuration en base | Scraping d'endpoints /metrics, configuration en fichiers | Checks de disponibilité |
| Point fort | Infrastructure hétérogène : serveurs, réseau, matériel | Applications cloud native, Kubernetes | Simplicité, pages de statut |
| Réseau et SNMP | Natif, des centaines de templates | Possible via un exporter | Basique |
| Alertes | Intégrées, avec escalades | Alertmanager à part | Intégrées, simples |
| Historique long | Oui, en base SQL | Limité sans Thanos ou Mimir | Limité |
| Courbe d'apprentissage | Moyenne à élevée | Élevée | Faible |
Mon avis : pour un parc de serveurs, de VM et d'équipements réseau, Zabbix est difficile à battre. Pour des microservices dans Kubernetes qui exposent déjà leurs métriques, le duo Grafana et Prometheus est plus naturel. Et pour savoir si trois sites répondent, Uptime Kuma s'installe en cinq minutes. Les trois cohabitent très bien : Grafana sait même afficher les données de Zabbix.
Zabbix publie une version LTS tous les 18 mois environ, supportée cinq ans, et deux versions standard entre deux LTS, supportées un an.
| Version | Sortie | Fin du support complet | Fin du support limité |
|---|---|---|---|
| 6.0 LTS | Février 2022 | Février 2025 | Février 2027 |
| 7.0 LTS | Juin 2024 | Juin 2027 | Juin 2029 |
| 7.4 | Juillet 2025 | À la sortie de 8.0 | Premier trimestre 2027 |
| 8.0 LTS | Prévue fin 2026 | Fin 2029 | Fin 2031 |
Début novembre 2026, la 8.0 LTS est en release candidate et n'est pas encore sortie. Ce cours utilise donc la 7.0 LTS, la seule version stable qui sera encore supportée dans deux ans. La migration vers 8.0 se fera de LTS à LTS, et on en parlera au dernier chapitre.
Zabbix demande plus d'investissement de départ qu'un outil de checks simple. En échange, il couvre un parc entier avec un seul outil, une seule base et une seule logique d'alerte. Le chapitre suivant installe le serveur, la base et le frontend.