📍 Lecture connexe : Zabbix 7 LTS en 2026 : supervision open-source en production — pour la vue d’ensemble et les arbitrages.
Une instance Zabbix vide n’a aucune valeur. La valeur naît dès qu’on supervise des hôtes réels et qu’on voit apparaître les premières métriques métier. Ce tutoriel prend une instance Zabbix 7 fraîchement installée et la connecte à un premier serveur Linux à superviser. À la fin, vous aurez un agent installé sur l’hôte cible, des items qui collectent CPU, mémoire, disque, réseau, des triggers qui alertent sur saturation, et un dashboard personnalisé qui agrège ces métriques.
Prérequis
- Une instance Zabbix 7 fonctionnelle (voir le tutoriel d’installation)
- Un second serveur Linux à superviser, accessible depuis le serveur Zabbix sur le port 10050
- Accès root ou sudo sur les deux machines
- Niveau attendu : débutant à intermédiaire — vous savez vous connecter en SSH et naviguer dans une interface web
- Temps estimé : environ 60 minutes
Étape 1 — Installer Zabbix Agent 2 sur l’hôte cible
L’agent collecte les données et les envoie au serveur. Sur l’hôte à superviser (qu’on appellera web01 dans la suite), on ajoute le dépôt Zabbix puis on installe le paquet zabbix-agent2. La procédure suit la même logique que pour le serveur, sauf qu’on n’installe que l’agent.
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
sudo dpkg -i zabbix-release_latest_7.0+debian12_all.deb
sudo apt update
sudo apt install -y zabbix-agent2L’agent 2 est installé en moins d’une minute. Le service systemd zabbix-agent2 est créé mais pas encore configuré pour parler au serveur.
Étape 2 — Configurer l’agent
Le fichier de configuration principal est /etc/zabbix/zabbix_agent2.conf. On édite trois directives essentielles : Server (l’IP du serveur Zabbix qui peut interroger cet agent), ServerActive (l’IP du serveur Zabbix à qui l’agent pousse les checks actifs), et Hostname (le nom de l’hôte tel qu’il apparaîtra dans Zabbix).
sudo sed -i "s/^Server=.*/Server=10.0.0.10/" /etc/zabbix/zabbix_agent2.conf
sudo sed -i "s/^ServerActive=.*/ServerActive=10.0.0.10/" /etc/zabbix/zabbix_agent2.conf
sudo sed -i "s/^Hostname=.*/Hostname=web01/" /etc/zabbix/zabbix_agent2.conf
sudo systemctl restart zabbix-agent2
sudo systemctl enable zabbix-agent2Remplacer 10.0.0.10 par l’IP réelle du serveur Zabbix. Le Hostname doit correspondre exactement à celui qu’on déclarera côté frontend (Zabbix utilise ce nom comme clé d’identification pour les checks actifs).
On vérifie que l’agent tourne et écoute sur le port 10050 : sudo ss -lntp | grep 10050 doit afficher une ligne LISTEN sur le port 10050.
Étape 3 — Tester la connectivité depuis le serveur Zabbix
Avant de créer l’hôte côté frontend, on confirme que le serveur Zabbix peut interroger l’agent. Depuis la machine du serveur Zabbix, on utilise l’utilitaire zabbix_get qui ouvre une connexion sur le port 10050 et demande une métrique. Ce test isole une éventuelle panne réseau ou firewall avant de complexifier.
# Sur le serveur Zabbix
zabbix_get -s 10.0.0.20 -p 10050 -k system.uptimeLa sortie attendue est un nombre (uptime du serveur web01 en secondes). Si on obtient « cannot connect to the agent: timeout », c’est que le firewall bloque le trafic 10050 entre serveur et agent. On vérifie côté agent (iptables -L, ufw status) et côté réseau (groupes de sécurité cloud, règles VPC). Si on obtient « not allowed », c’est que la directive Server côté agent ne contient pas l’IP du serveur Zabbix.
Étape 4 — Créer l’hôte dans le frontend
Dans le frontend Zabbix, on va dans Configuration → Hosts → Create host. On remplit le formulaire avec : Host name web01 (identique au Hostname côté agent), Visible name laissé vide pour utiliser le Host name, Groups Linux servers (créer le groupe si nécessaire). Dans Interfaces, on ajoute une interface Agent avec l’IP 10.0.0.20 et le port 10050.
L’onglet Templates est l’endroit où on lie le template officiel Linux by Zabbix agent. Ce template fournit déjà 50+ items (CPU, mémoire, disques, interfaces réseau, processus zombies, kernel, etc.) et 20+ triggers prêts à l’emploi. On le sélectionne dans la liste, on valide, puis on clique Add pour créer l’hôte.
Après quelques secondes, l’hôte apparaît dans la liste avec un voyant ZBX qui passe au vert dès que la première interrogation réussit. Si le voyant reste rouge, on hover dessus pour voir le message d’erreur précis et on retourne au test zabbix_get.
Étape 5 — Voir les premières métriques arriver
Dans Monitoring → Hosts, on retrouve web01 avec un compteur d’items. Cliquer sur Latest data ouvre une vue où chaque item affiche sa dernière valeur, son timestamp, et un graphe miniature. Au bout d’une minute, on voit les premières métriques : Load average, CPU utilization, Available memory, Filesystem usage. Cliquer sur un item ouvre un graphe historique avec la possibilité de zoomer sur une période.
À ce stade, l’hôte est supervisé. La supervision est passive : aucun trigger ne s’est encore déclenché parce qu’aucun seuil n’a été franchi. On va vérifier qu’au moins un trigger fonctionne en provoquant volontairement un dépassement.
Étape 6 — Comprendre les triggers et provoquer une alerte
On va dans Configuration → Hosts → web01 → Triggers. La liste affiche les triggers hérités du template Linux. Parmi eux : « Zabbix agent: Host name of Zabbix agent was changed », « Zabbix agent is not available », « Memory: lack of available memory », « Filesystem: space is critically low ».
Pour provoquer une alerte, on saturer temporairement la mémoire de web01. Sur la machine, on lance stress-ng --vm 2 --vm-bytes 90% --timeout 600s (installer stress-ng au préalable). Au bout de quelques minutes, la métrique mémoire chute, et le trigger Memory: lack of available memory bascule en état PROBLEM.
Dans Monitoring → Problems, l’incident apparaît avec sa sévérité (Warning, Average, High), son hôte concerné, son intitulé, et son timestamp d’ouverture. Le test confirme que la chaîne complète (collecte → évaluation trigger → état) fonctionne.
On arrête stress-ng ; après deux à trois minutes le trigger se résout automatiquement et passe en état OK. On note ce délai : il vient de la fonction d’agrégation utilisée dans le trigger (par exemple min(...,5m) qui demande que la valeur reste basse pendant cinq minutes avant de se résoudre).
Étape 7 — Construire un dashboard personnalisé
Les dashboards Zabbix sont construits par drag-and-drop dans le frontend. On va dans Dashboards → Create dashboard, on lui donne un nom (par exemple Linux infrastructure), et on ajoute des widgets. Le widget Graph (classic) permet d’afficher un item ou plusieurs sur un graphe temporel ; Top hosts affiche un classement des N hôtes les plus chargés sur une métrique ; Problems liste les problèmes en cours.
Une bonne première composition pour un dashboard infrastructure tient en quatre widgets. Top hosts pour CPU utilization (les plus chargés en haut). Top hosts pour Available memory inversé (les moins de mémoire libre). Graph affichant le trafic réseau total entrant et sortant sur la flotte. Problems filtré sur le groupe Linux servers.
Le dashboard s’enregistre automatiquement. On peut le partager à d’autres utilisateurs via les permissions (Privileges → Sharing), définir une période d’affichage par défaut, et le marquer comme dashboard de démarrage pour qu’il s’ouvre automatiquement à la connexion.
Étape 8 — Comprendre la latence de mise à jour
Une question récurrente quand on découvre Zabbix est : pourquoi les valeurs n’apparaissent-elles pas instantanément ? Trois facteurs jouent. L’intervalle de collecte de chaque item, configuré dans le template (typiquement 30 à 300 secondes) — c’est la fréquence à laquelle l’agent ou le serveur va interroger la métrique. La latence de queue entre la collecte et le traitement par le serveur, qui dépend de la NVPS courante et de la taille du pool de pollers. Le cache frontend qui rafraîchit la latest data toutes les 30 secondes par défaut.
Pour vérifier la santé de la queue, on va dans Reports → Queue overview ; aucune entrée ne devrait dépasser 30 secondes en régime stable. Si la queue grossit, c’est que le serveur ne suit pas le débit de collecte ; il faut soit augmenter StartPollers dans zabbix_server.conf, soit décharger via des proxies.
Étape 9 — Ajouter un second hôte rapidement
L’expérience devient intéressante avec plus d’un hôte. On répète les étapes 1 à 4 sur un second serveur (par exemple db01) en moins de 10 minutes. La différence avec un serveur web : on lui lie un template additionnel PostgreSQL by Zabbix agent 2 en plus du template Linux, ce qui ajoute 30+ items spécifiques PostgreSQL (connexions actives, taille de la base, transactions par seconde, replication lag).
Le template PostgreSQL nécessite que l’agent 2 puisse se connecter à PostgreSQL. On crée donc un utilisateur PostgreSQL dédié avec droits en lecture sur pg_stat_*, on ajoute la chaîne de connexion dans la configuration de l’agent (macro {$PG.URI}), et on relance l’agent. Les détails varient selon la version PostgreSQL et sont documentés dans la fiche du template officiel.
Étape 10 — Comprendre les macros
Les macros Zabbix sont des variables qui paramètrent les items et triggers sans toucher au template. Une macro est définie au niveau global, template ou hôte ; la résolution suit la hiérarchie. Par exemple {$AGENT.TIMEOUT} contrôle le timeout des checks agent ; on peut le surcharger pour un hôte spécifique sans modifier le template.
Les macros permettent de personnaliser le comportement des templates sans les forker. Le template Linux contient par exemple {$CPU.UTIL.CRIT} = 90 % par défaut ; sur un serveur de batch qui tourne légitimement à 95 %, on définit la macro à 98 % au niveau de cet hôte spécifique, et le seuil change uniquement pour lui. Cette élégance est ce qui rend les templates Zabbix vraiment industrialisables.
Étape 11 — Surveiller la santé de l’agent lui-même
Un agent qui ne répond plus est silencieux : sans trigger dédié, on ne le saurait pas. Heureusement, le template Linux inclut le trigger Zabbix agent is not available qui se déclenche après deux échecs consécutifs de l’item système zabbix[host,agent,available]. C’est ce trigger qu’on garde précieusement : si vous le désactivez, vous perdez la garantie de remontée. Le tester en arrêtant volontairement l’agent (systemctl stop zabbix-agent2) fait partie des passages obligés pour valider qu’on est notifié quand ça compte.
Étape 12 — Visualiser l’historique d’un item
Cliquer sur un item dans Latest data ouvre un graphe avec sélecteur de période : 1h, 6h, 24h, 7j, 30j, période personnalisée. Le graphe affiche en bleu la métrique brute (history) sur les périodes courtes, et en orange les agrégats (trends) sur les périodes longues. Cette double représentation permet de zoomer sur l’incident d’hier en haute résolution tout en gardant la tendance mensuelle pour la planification de capacité.
Pour exporter les données vers un outil tiers (Excel, Grafana, BI), on utilise l’API JSON-RPC ou directement l’export CSV depuis Reports → Audit → Latest data. Pour l’usage récurrent, l’API est plus pratique car scriptable.
Étape 13 — Préparer la suite
À ce stade, vous avez une instance Zabbix qui supervise plusieurs serveurs avec des templates officiels, des triggers fonctionnels, et un dashboard. C’est largement suffisant pour démarrer en production sur une dizaine d’hôtes. Pour aller plus loin, deux directions s’offrent : maîtriser les templates personnalisés et l’auto-discovery LLD pour industrialiser, ou approfondir les notifications pour ne pas se faire submerger d’alertes en pleine nuit.
Étape 14 — Préparer la mise à l’échelle
Démarrer avec deux ou trois hôtes est un excellent terrain d’apprentissage, mais la vraie valeur émerge quand on supervise des dizaines puis des centaines d’hôtes. Trois patterns à connaître pour ne pas se faire submerger. D’abord, organiser les hôtes par tags métier (env=prod, service=api, region=eu-west) plutôt que par groupes seuls — les tags filtrent dynamiquement les dashboards et les notifications. Ensuite, automatiser la création des hôtes via API plutôt que clics frontend dès qu’on dépasse une dizaine — un script de provisioning qui lit un CSV ou une CMDB sera détaillé dans un tutoriel ultérieur de cette série. Enfin, surveiller la NVPS (New Values Per Second) du serveur lui-même : Reports → Server info montre la valeur ; tant qu’elle reste sous 70 % de la capacité théorique de la machine, on est dans une zone confortable.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Voyant ZBX rouge avec « not allowed » | Directive Server de l’agent ne contient pas l’IP du serveur Zabbix |
Éditer /etc/zabbix/zabbix_agent2.conf et redémarrer l’agent |
| Items en statut Unsupported après liaison du template | Hostname côté agent différent du Host name côté frontend | S’assurer que les deux noms correspondent exactement, casse comprise |
| Métriques qui n’apparaissent jamais en mode active checks | Directive ServerActive manquante ou pointe vers une mauvaise IP |
Configurer ServerActive et vérifier que le port 10051 est ouvert sortant |
| Trigger qui ne se déclenche pas malgré dépassement visible | Macro de seuil héritée d’un parent dont la valeur n’est pas atteinte | Vérifier la valeur réelle de la macro dans Configuration → Hosts → host → Macros (vue résolue) |
| Dashboard qui rafraîchit trop lentement | Période sélectionnée trop large + widgets nombreux | Réduire la période (1h ou 6h en monitoring temps réel) et limiter à 5-7 widgets par dashboard |