Sommaire

L’état de la supervision open-source en 2026
Pourquoi Zabbix 7 LTS s’impose
Architecture d’un déploiement Zabbix moderne
Concepts essentiels : hôte, item, trigger, template
La stack 2026 : Zabbix 7 + PostgreSQL + Nginx
Les nouveautés majeures de la 7.0
Les tutoriels de cette série
Erreurs fréquentes à éviter
FAQ
Ressources officielles

L’état de la supervision open-source en 2026

Le paysage de la supervision applicative et infrastructure a connu une bascule nette entre 2020 et 2026. D’un côté, l’écosystème Prometheus + Grafana + Loki s’est imposé comme standard de facto pour les architectures cloud-native, conteneurisées et microservices. De l’autre, la supervision « classique » — celle qui couvre serveurs physiques, équipements réseau SNMP, applications monolithiques, bases de données, services métier — a vu plusieurs solutions historiques décrocher (Nagios Core stagne, EyesOfNetwork est officiellement non maintenu depuis octobre 2022, Cacti perd du terrain) tandis que d’autres se sont consolidées.

Dans ce paysage, trois noms restent dominants en 2026 sur la supervision serveur traditionnelle : Zabbix, Centreon et Checkmk. Zabbix est le seul des trois entièrement open-source en édition communautaire complète, sans bridage de fonctionnalités payantes pour la version gratuite. Centreon a basculé une partie de ses modules (Cloud Discovery, MAP, BAM) en édition Business payante. Checkmk fonctionne sur le même modèle freemium avec une Raw Edition limitée. Zabbix, lui, livre tout dans la même édition GPL : agents, proxy, haute disponibilité, modèles métier, API, dashboards modernes — sans couche commerciale verrouillée.

La version 7.0 LTS, sortie en juin 2024 et arrivée en mai 2026 à la révision 7.0.25 selon les notes de release officielles, est supportée jusqu’au 30 juin 2029 d’après la politique de cycle de vie Zabbix : trois ans de support complet (correctifs fonctionnels, sécurité, bugs) jusqu’en juin 2027, puis deux ans de support limité (sécurité et bugs critiques uniquement) jusqu’en juin 2029. Cette fenêtre de cinq ans rend la 7.0 idéale pour un déploiement en production : on bâtit une fois, on la garde jusqu’au prochain LTS sans réinstaller.

Pourquoi Zabbix 7 LTS s’impose

Cinq raisons concrètes font de Zabbix 7 LTS le choix par défaut en 2026 pour une équipe qui veut superviser à la fois des serveurs Linux/Windows, des équipements réseau, des applications web, et des services métier. La première est la couverture native : aucun outil tiers n’est nécessaire pour démarrer, l’agent Zabbix natif tourne sur la quasi-totalité des systèmes (Linux, Windows, macOS, AIX, Solaris, FreeBSD, Raspberry Pi). La deuxième est la gestion des grandes flottes : un serveur Zabbix standard tient sans difficulté plusieurs milliers d’hôtes ; au-delà, le mécanisme de proxies distribués permet d’absorber des dizaines de milliers d’éléments supervisés sans dégradation.

La troisième raison est la richesse du modèle : Zabbix introduit la notion de template qui regroupe items (métriques), triggers (seuils), graphes, et règles d’auto-discovery dans un objet réutilisable. On définit une fois la supervision PostgreSQL, on l’applique à 50 hôtes, on la modifie et la mise à jour se propage. Cette discipline de modélisation manque cruellement à Prometheus dont les exporters et règles vivent dans des fichiers YAML séparés, à maintenir synchronisés à la main.

La quatrième raison est l’API. Zabbix expose toute son administration via une API JSON-RPC 2.0 documentée et stable. Tout ce qu’on fait dans le frontend, on peut le faire en automatisé : créer un hôte, lui appliquer un template, déclencher une maintenance, exporter une configuration. C’est ce qui permet d’intégrer Zabbix dans une chaîne CI/CD, de provisionner via Terraform, ou de générer dynamiquement la supervision à partir d’un inventaire CMDB.

La cinquième raison est l’écosystème de modèles officiels. Le projet maintient plusieurs centaines de modèles prêts à l’emploi pour des applications, bases de données, équipements réseau (Cisco, Juniper, HP, Dell, Mikrotik), services cloud (AWS, Azure, GCP), conteneurs (Docker, Kubernetes), bases de données (PostgreSQL, MySQL, Oracle, MSSQL), services web (Nginx, Apache, HAProxy). Ils s’importent en quelques clics et donnent immédiatement une supervision complète sans devoir tout configurer à la main.

Architecture d’un déploiement Zabbix moderne

Un déploiement Zabbix bien conçu en 2026 combine cinq composants principaux. Le serveur Zabbix est le cœur logiciel : il reçoit les données collectées, évalue les triggers, déclenche les actions (notifications, escalade, exécutions de scripts), et expose l’API. Il tourne sur un seul nœud en mode standalone, ou sur plusieurs en mode haute disponibilité native introduit en 6.0 et stabilisé en 7.0.

La base de données stocke à la fois la configuration (hôtes, templates, utilisateurs) et l’historique des métriques. PostgreSQL 14+ avec l’extension TimescaleDB est la combinaison recommandée pour les déploiements modernes : la rétention longue durée des métriques bénéficie énormément de la compression et du partitionnement automatique TimescaleDB. MySQL 8.0+ et MariaDB 10.5+ restent supportés, mais demandent plus de tuning pour atteindre des performances comparables.

L’interface web (frontend) est une application PHP servie par Nginx ou Apache. Elle parle à la base de données et au serveur Zabbix via le protocole interne. C’est elle qui héberge les dashboards, les écrans d’administration, et l’éditeur de templates.

Les agents tournent sur chaque hôte supervisé. L’agent Zabbix 2 (écrit en Go, introduit en 4.4 en expérimental et déclaré production-ready avec la 5.0 de mai 2020) coexiste avec l’ancien agent C ; il est plus économe en ressources et supporte un système de plugins natif. Pour les équipements qui ne peuvent pas faire tourner d’agent (switches, routeurs, imprimantes), Zabbix utilise SNMP v1/v2c/v3, IPMI ou des checks HTTP/SSH.

Les proxies Zabbix, enfin, jouent le rôle de relais : un proxy installé dans une agence collecte les métriques des hôtes locaux et les pousse au serveur central via une connexion sortante. Ce mécanisme résout deux problèmes en une fois : la traversée des firewalls (le proxy initie la connexion vers le central), et la résilience réseau (le proxy bufferise localement quand la liaison vers le central tombe).

Concepts essentiels : hôte, item, trigger, template

Quatre concepts structurent toute la modélisation Zabbix. Les confondre ou les apprendre dans le mauvais ordre est la cause numéro un des intégrations bancales. L’hôte est l’entité supervisée : un serveur, un switch, une application, un service métier abstrait. Chaque hôte a une ou plusieurs interfaces (IP agent, SNMP, IPMI, JMX) et appartient à un ou plusieurs groupes d’hôtes.

L’item est une métrique collectée. Un item définit ce qu’on collecte (une commande agent, une OID SNMP, une requête SQL, un check HTTP), à quel intervalle, et combien de temps les données sont conservées. Le nom d’un item respecte une nomenclature précise : vm.memory.size[available] pour la mémoire libre, net.if.in[eth0] pour le trafic entrant sur eth0. Cette nomenclature est documentée dans la page items de la documentation.

Le trigger est une expression booléenne qui évalue un ou plusieurs items pour générer un problème. Un trigger n’est pas un seuil simple : c’est une formule qui combine des fonctions temporelles (last, avg, min, max, count, change), des opérateurs logiques, et des constantes. Par exemple : last(/HostA/system.cpu.util) > 90 and avg(/HostA/system.cpu.util,5m) > 80 ne déclenche que si la dernière valeur dépasse 90 % ET que la moyenne sur 5 minutes dépasse 80 %, ce qui filtre les pics ponctuels.

Le template regroupe items, triggers, graphes, règles de découverte et tags dans un bundle réutilisable. Quand on lie un template à un hôte, l’hôte hérite automatiquement de tout le contenu. Modifier le template propage le changement à tous les hôtes liés. C’est cette mécanique d’héritage qui permet de gérer mille hôtes avec dix templates plutôt que mille configurations indépendantes.

La stack 2026 : Zabbix 7 + PostgreSQL + Nginx

La combinaison technique recommandée pour démarrer un déploiement neuf en 2026 ressemble à ceci. Côté OS, Debian 12 (Bookworm) ou Ubuntu 24.04 LTS (Noble Numbat) — supportés par les paquets officiels Zabbix selon le tableau d’installation. Côté base, PostgreSQL 16 ou 17 avec l’extension TimescaleDB 2.x activée sur les tables d’historique. Côté frontend, Nginx avec PHP 8.2+. Côté serveur Zabbix, la dernière 7.0.x LTS.

Pour les agents, on installe Zabbix Agent 2 sur tous les serveurs Linux et Windows. Introduit en 4.4 comme expérimental et stabilisé en production avec la 5.0 (mai 2020), il supporte les plugins en natif : on peut superviser PostgreSQL, MySQL, Docker, Nginx, MongoDB, Memcached, Redis sans installer aucun composant supplémentaire — il suffit d’activer le plugin et de pointer la connexion. La liste à jour vit dans la page intégrations officielles.

Pour le stockage long terme et l’analyse rétrospective, on utilise la rétention différenciée Zabbix : les valeurs brutes (history) sont conservées 7 à 30 jours, les agrégats horaires (trends) jusqu’à 365 jours ou plus. Avec TimescaleDB compressé, garder un an de trends sur cinq mille hôtes tient sur quelques dizaines de gigaoctets, ce qui rend le stockage abordable même sur un VPS modeste.

Les nouveautés majeures de la 7.0

La version 7.0 LTS apporte plusieurs ruptures qui méritent qu’on les connaisse. La première est la haute disponibilité native : on peut désormais monter un cluster de plusieurs nœuds Zabbix Server, avec bascule automatique en cas de panne du nœud primaire. Le mécanisme repose sur l’enregistrement périodique du statut de chaque nœud dans la base de données partagée ; si le primaire ne renouvelle pas son lease, un standby prend la main. Plus besoin de Pacemaker, Keepalived ou Corosync.

La deuxième est la supervision web synthétique de bout en bout. Le scénario web a été refondu pour exécuter de vrais navigateurs headless (Chromium via Selenium WebDriver), pas juste des requêtes HTTP. On peut donc tester un parcours utilisateur complet, capturer les métriques de performance perçue (LCP, FID, CLS), et alerter sur dégradations.

La troisième est l’authentification multi-facteurs native. Avant la 7.0, on déléguait à un proxy SAML ou un IdP externe. Désormais Zabbix supporte TOTP (Google Authenticator, Authy) et Duo en natif, configuration par utilisateur ou par groupe.

La quatrième est l’arrivée d’API tokens stables comme alternative au login utilisateur. Avant, l’authentification API se faisait via user.login avec un mot de passe, qui retournait un token de session court. Maintenant on génère depuis le frontend un API token nommé, attaché à un utilisateur, à durée de vie configurable. C’est le mécanisme à privilégier pour toute intégration CI/CD ou automatisation.

La cinquième est la haute disponibilité des proxies. On peut désormais grouper plusieurs proxies en cluster ; les hôtes assignés au groupe sont automatiquement répartis et redistribués si un proxy tombe. Cette fonctionnalité élimine le single point of failure côté collecte.

Dimensionner correctement son instance

Le dimensionnement matériel est l’un des points sur lesquels les déploiements Zabbix échouent le plus souvent. La règle pragmatique repose sur trois leviers : nombre d’hôtes, intervalle moyen de collecte, et durée de rétention des métriques brutes. Un calcul d’ordre de grandeur consiste à estimer la NVPS (New Values Per Second), c’est-à-dire le nombre de valeurs reçues par seconde : NVPS = (nombre d’items × fréquence en Hz). Un déploiement à 1 000 hôtes avec 80 items chacun collectés toutes les 60 secondes produit environ 1 333 NVPS, ce que tient un serveur 8 vCPU + 16 Go RAM avec PostgreSQL + TimescaleDB sur un disque NVMe.

Le second levier est la rétention. Conserver les valeurs brutes (history) trois jours et les agrégats horaires (trends) un an est un compromis solide pour la plupart des contextes : on garde la précision pour le débogage à chaud, et la tendance longue pour les rapports de capacité. Étendre la rétention history à 30 jours sans TimescaleDB triple à quintuple la taille de la base, ce qui peut faire saturer le disque sans qu’on s’en rende compte avant un incident.

Le troisième levier est la séparation des rôles. Sur des déploiements de plus de 500 hôtes, on sépare la base de données du serveur Zabbix sur deux machines distinctes. La base profite alors de toute la mémoire disponible pour son cache, et le serveur Zabbix n’est plus contraint par les latences disque pendant les pics de calcul des triggers.

Les tutoriels de cette série

Pour chaque sujet ci-dessous, un tutoriel pas-à-pas est disponible. Ils sont conçus pour être lus dans l’ordre quand on monte une instance neuve, ou consultés indépendamment quand on cherche une recette précise.

Installer Zabbix 7 sur Debian 12 ou Ubuntu 24.04 — paquets officiels, base PostgreSQL + TimescaleDB, frontend Nginx, premier login. Lire le tutoriel
Premier hôte supervisé : items, triggers, dashboards — installer l’agent 2, créer l’hôte, lier un template, voir les premières métriques. Lire le tutoriel
Templates et auto-discovery LLD — créer un template métier, automatiser la découverte des disques, partitions, interfaces. Lire le tutoriel
Zabbix Agent 2 et plugins natifs — superviser PostgreSQL, Docker, Nginx sans exporter externe. Lire le tutoriel
Notifications : email, Telegram et escalade — media types, actions, conditions, escalade, fenêtres de garde. Lire le tutoriel
Zabbix Proxy : superviser un site distant — installer le proxy, l’enregistrer auprès du serveur, déplacer des hôtes, mode actif vs passif. Lire le tutoriel
Haute disponibilité native Zabbix 7 — monter un cluster de nœuds serveur, configurer le lease, tester le failover. Lire le tutoriel
API JSON-RPC et automatisation Python avec pyzabbix — token API, scripts de provisionnement, intégration CI. Lire le tutoriel

Erreurs fréquentes à éviter

Erreur	Cause	Solution
Items en statut Unsupported juste après la liaison du template	L’agent ne supporte pas la métrique demandée ou l’utilisateur agent n’a pas les droits	Tester avec `zabbix_get -s host -k cle` depuis le serveur, lire le message d’erreur retourné
Frontend qui affiche « Zabbix server is not running »	Le frontend ne joint pas le serveur sur le port 10051	Vérifier la configuration `$ZBX_SERVER` dans `/etc/zabbix/web/zabbix.conf.php` et le firewall
Triggers qui se déclenchent en boucle sur des pics ponctuels	Trigger basé uniquement sur la dernière valeur	Utiliser des fonctions agrégées : `avg(...,5m) > 80` au lieu de `last(...) > 80`
Disque base de données qui sature après quelques mois	Rétention history trop longue ou TimescaleDB pas configuré	Activer la compression TimescaleDB sur les tables history et trends, viser 7-30 jours pour history
Templates importés en doublon avec des noms similaires	Plusieurs versions du même template officiel importées sans suppression	Maintenir un import unique, dater les versions, supprimer les anciennes après vérification
Agent installé mais aucune donnée ne remonte	L’hôte est en mode passive mais le firewall bloque le 10050 entrant	Soit ouvrir le 10050 entrant côté hôte, soit basculer en active checks depuis l’agent
Notifications email qui partent toutes les 30 secondes	Action sans étape d’escalade, trigger qui flap	Configurer une étape avec délai, activer l’OK message seulement, lisser le trigger avec `min(...,5m)`

FAQ

Zabbix ou Prometheus, que choisir en 2026 ?
Les deux ne couvrent pas exactement le même besoin. Prometheus excelle sur les métriques d’applications cloud-native, instrumentées via SDK ou exporters, dans un environnement Kubernetes. Zabbix excelle sur les serveurs traditionnels, les équipements réseau SNMP, les bases de données, les services métier, et la supervision de bout en bout d’une infrastructure hybride. Beaucoup d’organisations font tourner les deux : Prometheus pour les workloads conteneurisés, Zabbix pour le reste. Aucune obligation de choisir l’un contre l’autre.

Zabbix 7.0 LTS ou 7.4 ?
La 7.4 est une release dite « point » : nouvelles fonctionnalités, support court (six mois après la sortie de la 7.6 prévue fin 2026). Pour la production, on reste en 7.0 LTS jusqu’à l’arrivée de la prochaine LTS (probablement 8.0 mi-2027). Les point releases sont utiles pour tester en avant-première, pas pour bâtir un déploiement durable.

Combien d’hôtes peut superviser un seul serveur Zabbix ?
Un serveur Zabbix sur un VPS de 8 vCPU et 16 Go de RAM avec PostgreSQL + TimescaleDB tient confortablement 2 000 hôtes typiques (chacun avec 50 à 100 items collectés à intervalle de 60 secondes). Au-delà, soit on scale verticalement la base, soit on déploie des proxies pour décentraliser la collecte. La page exigences matérielles donne les ordres de grandeur officiels selon la taille cible.

Faut-il TimescaleDB ou PostgreSQL standard suffit ?
Pour un déploiement de moins de 200 hôtes avec rétention courte, PostgreSQL standard suffit. Au-delà de 500 hôtes ou pour conserver plus de 60 jours d’historique, TimescaleDB devient essentiel : la compression typique atteint 80 à 95 % sur les tables d’historique, la performance des requêtes sur les tendances est multipliée par 10 ou plus. L’extension est gratuite (Apache 2.0).

Zabbix supporte-t-il les conteneurs et Kubernetes ?
Oui, mais avec des forces et faiblesses différentes selon le scénario. Pour superviser le runtime Docker (conteneurs, images, networks) sur des hôtes individuels, le plugin Docker de l’Agent 2 est la voie naturelle. Pour superviser un cluster Kubernetes complet (pods, deployments, namespaces, métriques cAdvisor, événements), kube-prometheus-stack reste mieux outillé que Zabbix. Beaucoup d’équipes choisissent Zabbix pour les hôtes Kubernetes (workers, control plane VM) et Prometheus pour les workloads dans les pods.

Comment migrer depuis Nagios, Centreon ou EyesOfNetwork ?
Il n’y a pas de migration automatique : la modélisation Zabbix (items + templates + triggers) diffère trop de celle de Nagios (services + hosts). La méthode pragmatique est d’inventorier les hôtes et services supervisés dans l’ancien outil, de chercher dans le catalogue de templates Zabbix l’équivalent (souvent disponible), et d’importer en masse via l’API. La phase la plus longue est le re-paramétrage des seuils et notifications, qui demande une revue métier. Compter de quelques semaines à plusieurs mois selon la taille du parc.

Zabbix peut-il remplacer Grafana ?
Pas directement. Zabbix dispose de dashboards et de graphes natifs corrects pour la majorité des besoins, mais Grafana reste plus puissant pour la datavisualisation poussée et la corrélation multi-sources. Le plugin Grafana pour Zabbix permet d’utiliser Zabbix comme datasource et de construire des dashboards Grafana avec ses données, ce qui combine le meilleur des deux mondes.

Zabbix 7 LTS en 2026 : supervision open-source en production