Zabbix a une réputation : puissant, complet, et un peu austère. Elle est méritée, et la deuxième moitié de la phrase tient surtout aux installations faites en suivant le tutoriel de démarrage puis jamais retouchées. Une base mal dimensionnée, des modèles modifiés en place, des alertes envoyées à tout le monde pour tout : au bout de six mois, plus personne ne lit les notifications et l'outil passe pour coupable.
Ce guide décrit la façon dont nous déployons et exploitons Zabbix chez nos clients. Il ne refait pas la documentation officielle : il dit ce que nous choisissons, dans quel ordre, et pourquoi.
01À qui s'adresse ce guide
Aux administrateurs qui connaissent Linux, PostgreSQL et les bases de la supervision, et qui veulent une plateforme Zabbix tenable dans la durée : plusieurs dizaines à plusieurs milliers d'hôtes, plusieurs sites ou plusieurs clients, une astreinte. Si vous cherchez quelque chose de plus léger, la page quel outil choisir vous orientera sans doute ailleurs, et c'est très bien ainsi.
02Pourquoi la 8.0, et quand
Zabbix 8.0 est en release candidate depuis le 1er octobre 2026, la version finale est attendue dans les semaines qui suivent. Ce guide est écrit pour elle et vérifié sur la RC. Les commandes d'installation et les noms de paquets seront revérifiés à la sortie ; tout ce qui relève de l'architecture et de la méthode est indépendant de ce calendrier.
Nous écrivons pour la 8.0 parce qu'elle sera la version de support long des années à venir : support complet jusqu'au troisième trimestre 2029 et support limité jusqu'en 2031. Une nouvelle plateforme montée aujourd'hui en 7.0 devrait de toute façon migrer dans l'année.
Notre règle de prudence, que nous appliquons à nos propres plateformes : une nouvelle installation peut partir en 8.0 dès la version finale, une migration de production attend la première version corrective. Le chapitre 06 détaille cette migration depuis la 7.0 LTS, qui reste aujourd'hui la base installée la plus répandue.
03L'architecture visée
Le guide construit progressivement une plateforme de ce type. Chaque brique est facultative en dessous d'une certaine taille, et le chapitre 01 dit où sont les seuils.
| Brique | Rôle | Indispensable à partir de |
|---|---|---|
| Deux serveurs Zabbix en haute disponibilité | Collecte, calcul des déclencheurs, alertes | Dès qu'une astreinte dépend de la supervision |
| PostgreSQL avec TimescaleDB | Configuration et historique compressé | Toujours, c'est notre base de référence |
| Frontal web derrière un proxy inverse | Interface et API | Toujours |
| Proxies Zabbix | Collecte locale par site ou par client | Un second site, une zone isolée, ou 500 hôtes |
| Agent 2 sur chaque serveur, en mode actif | Collecte système et applicative | Toujours |
| Grafana branché sur Zabbix | Tableaux de bord de direction | Quand quelqu'un réclame de jolis graphiques |
| Sonde externe indépendante | Surveiller la supervision elle-même | Toujours, sans exception |
04Les six chapitres
Architecture et haute disponibilité
Dimensionner en valeurs par seconde, installer PostgreSQL et TimescaleDB, monter deux serveurs en grappe, et régler les caches avant qu'ils ne saturent.
CHAPITRE 02Agents, proxies et autoregistration
L'agent 2 en mode actif, le chiffrement PSK, l'enregistrement automatique des hôtes, et les proxies par site ou par client, regroupés pour la bascule.
CHAPITRE 03Modèles, macros et découverte
Ne jamais modifier un modèle officiel, surcharger par macros contextuelles, superviser Proxmox VE et Ceph, et organiser le tout par étiquettes.
CHAPITRE 04Déclencheurs, corrélation et escalades
Des expressions qui prévoient plutôt qu'elles ne constatent, des dépendances qui éteignent les alertes en cascade, et des escalades qui réveillent la bonne personne.
CHAPITRE 05API et configuration en code
Jetons d'API, scripts Python avec la bibliothèque officielle, maintenance posée automatiquement avant une intervention, modèles versionnés dans Git.
CHAPITRE 06Migrer de 7.0 vers 8.0
Les versions minimales de base et de PHP, les macros supprimées qui cassent les notifications, l'ordre de montée et le plan de retour arrière.
05Ce que ce guide ne couvre pas
- Le déploiement en conteneurs ou sur Kubernetes, qui change l'exploitation sans changer la méthode.
- MySQL et MariaDB comme base principale : ils fonctionnent, mais nous ne les retenons plus pour les plateformes que nous construisons.
- La supervision des journaux et le traitement d'événements complexes annoncés pour la 8.0, que nous documenterons une fois éprouvés en production.
- Zabbix Cloud, l'offre hébergée de l'éditeur.
Une supervision qui veille pendant que vous dormez
Nous concevons, installons et exploitons des plateformes de supervision pour des PME, des hébergeurs et des collectivités : Zabbix, Prometheus et Grafana, ou plus léger quand le besoin l'est. Reprise d'une supervision existante, réglage des alertes qui sonnent pour rien, astreinte : nous intervenons au forfait comme au long cours.