Supervision avec Zabbix

Le serveur est prêt. On ajoute maintenant de vraies machines à superviser. Trois pièces entrent en jeu : l'agent 2 installé sur chaque machine, l'hôte déclaré dans Zabbix, et le template qui apporte d'un coup des dizaines de métriques et de triggers déjà réglés.

Agent ou agent 2

Zabbix maintient deux agents. L'agent historique est écrit en C. L'agent 2, écrit en Go, est le successeur : il gère les checks actifs en parallèle, garde ses données en mémoire tampon si le serveur est injoignable, et embarque des plugins pour Docker, PostgreSQL, MySQL, Redis, MongoDB ou les certificats TLS.

Sur une machine récente, prenez l'agent 2. Les deux utilisent le même protocole et les mêmes clés d'items de base, donc les templates « by Zabbix agent » fonctionnent avec l'un comme avec l'autre.

Installer l'agent 2 sur un serveur Linux

Sur la machine à superviser, on ajoute le même dépôt qu'au chapitre précédent, puis on n'installe que l'agent :

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb
apt update
apt install -y zabbix-agent2

La configuration tient en quelques lignes dans /etc/zabbix/zabbix_agent2.conf :

Server=10.0.0.10
ServerActive=10.0.0.10
Hostname=web-01
HostMetadata=linux web

systemctl restart zabbix-agent2
systemctl enable zabbix-agent2

Le Hostname est la cause numéro un des checks actifs qui ne remontent pas. S'il ne correspond pas au nom de l'hôte dans l'interface, au caractère près, le serveur ignore l'agent et le journal de l'agent affiche host [web-01] not found.

Tester l'agent

Sur la machine supervisée, l'agent peut évaluer une clé localement :

zabbix_agent2 -t system.cpu.load[all,avg1]

Depuis le serveur Zabbix, zabbix_get interroge l'agent en mode passif, comme le ferait le serveur :

apt install -y zabbix-get
zabbix_get -s 10.0.0.21 -k agent.ping

Une réponse 1 confirme que le réseau et le paramètre Server sont corrects. Un délai dépassé pointe vers le pare-feu.

Déclarer un hôte à la main

Dans Data collection > Hosts > Create host :

1. Host name : web-01, identique au Hostname de l'agent.
2. Templates : Linux by Zabbix agent active pour les checks actifs, ou Linux by Zabbix agent pour le mode passif.
3. Host groups : Linux servers, ou un groupe à vous comme Production/Web.
4. Interfaces : une interface Agent avec l'adresse IP, utile même en mode actif pour zabbix_get et les checks passifs éventuels.

Au bout de quelques minutes, Monitoring > Latest data affiche le CPU, la mémoire, les disques, le réseau, les processus. Le template a créé une centaine d'items et une trentaine de triggers sans que vous en écriviez un seul.

L'enregistrement automatique

Déclarer chaque hôte à la main ne passe pas à l'échelle. Avec l'enregistrement automatique, un agent actif qui contacte le serveur pour la première fois est ajouté tout seul, dans le bon groupe, avec le bon template. C'est là que sert HostMetadata.

Dans Alerts > Actions > Autoregistration actions, créez une action :

Une deuxième action avec la condition HostMetadata contains web peut ajouter le template Nginx, une troisième avec db le template PostgreSQL. Les métadonnées décrivent le rôle de la machine, les actions en déduisent la supervision. Combiné à un outil de déploiement, ajouter un serveur à la supervision devient un non-sujet : on installe l'agent avec les bonnes métadonnées, Zabbix fait le reste.

Comprendre les templates

Un template regroupe des items, des triggers, des graphiques, des tableaux de bord et des règles de découverte. Zabbix 7.0 en livre plusieurs centaines, rangés par famille.

Un hôte peut être lié à plusieurs templates. Un template peut aussi en inclure d'autres, ce qui permet de construire un template « Serveur web maison » qui lie Linux, Nginx et le certificat TLS d'un coup.

Ne jamais modifier un template officiel

C'est la règle la plus importante de ce chapitre. Les templates officiels sont mis à jour à chaque version de Zabbix. Si vous changez un seuil directement dedans, la prochaine importation écrase votre modification, ou vous empêche de l'importer.

Pour adapter un template, on passe par les macros utilisateur. Les seuils des templates officiels ne sont pas écrits en dur : ils lisent des macros comme {$CPU.UTIL.CRIT} ou {$VFS.FS.PUSED.MAX.CRIT}. On surcharge la macro au bon niveau.

La valeur la plus proche de l'hôte gagne. Un serveur de calcul qui tourne à 95 % de CPU en permanence reçoit {$CPU.UTIL.CRIT} à 99 sur sa fiche, sans toucher au template. Pour un changement plus profond, clonez le template sous un autre nom, et assumez de le maintenir.

Les macros avec contexte

Une macro peut prendre un contexte, entre guillemets après deux-points. C'est ce qui permet de régler un seuil par système de fichiers :

{$VFS.FS.PUSED.MAX.CRIT}            = 90
{$VFS.FS.PUSED.MAX.CRIT:"/var/lib/postgresql"} = 95

Tous les disques alertent à 90 %, sauf la partition de la base qui alerte à 95 %. Le template n'a pas bougé.

Organiser les groupes et les tags

Les groupes d'hôtes servent aux droits d'accès et aux filtres. Une hiérarchie par environnement puis par rôle fonctionne bien : Production/Web, Production/Bases, Recette/Web. Zabbix comprend la barre oblique comme un niveau d'arborescence.

Les tags complètent les groupes. Un tag service:facturation ou équipe:infra sur un hôte, un template ou un trigger se retrouve sur les problèmes générés. On s'en sert ensuite pour filtrer les vues et router les alertes vers la bonne équipe, ce qu'on verra au chapitre 5.

Et Windows ?

L'agent 2 existe pour Windows sous forme de MSI. L'installeur demande l'adresse du serveur et le nom d'hôte, et installe un service. Le template Windows by Zabbix agent active couvre CPU, mémoire, disques, services Windows et journaux d'événements.

Avec l'agent, les templates et l'enregistrement automatique, un parc de cent serveurs se supervise aussi facilement qu'un seul. Le chapitre suivant ouvre le capot des templates : comment écrire ses propres items et triggers quand rien de prêt n'existe.