Zabbix fait partie de ces outils qui n’ont jamais cherché à suivre les modes. Là où d’autres solutions ont multiplié les micro‑services, les pipelines distribués et les dépendances externes, Zabbix a conservé une architecture lisible, cohérente, centralisée. Ce choix n’a rien d’un compromis : il permet une supervision prévisible, maîtrisable, et surtout auditable. La version 7.0 LTS poursuit cette logique en renforçant la stabilité et la capacité d’absorption de charge, sans renier les fondations du projet.
Pour comprendre Zabbix, il faut accepter son ADN : un serveur maître, des agents, des proxys, et une base SQL qui structure l’ensemble. C’est une architecture assumée, qui ne cherche pas à être “cloud native”, mais à être fiable. Et c’est précisément ce qui en fait un outil pertinent dans de nombreux environnements.
1. Philosophie Zabbix : supervision centralisée, agent + proxy, SQL, pollers
Zabbix repose sur une idée simple : un serveur central orchestre tout. Les agents collectent les données, les proxys absorbent la latence et structurent les environnements distribués, et la base SQL stocke l’intégralité des informations. Rien n’est dispersé, rien n’est délégué à des services externes. Cette centralisation permet une cohérence totale du modèle de données, des alertes, des dépendances et des escalades.
Dans cette logique, les pollers jouent un rôle essentiel : ils interrogent les hôtes ou reçoivent leurs données, selon qu’ils fonctionnent en mode actif ou passif. L’agent2, plus moderne et modulaire, étend encore cette capacité en permettant des collectes plus propres et plus flexibles.
Prenons par exemple : Une entreprise de 300 postes et 40 serveurs déploie Zabbix avec un serveur central et deux proxys distants. Les agents actifs remontent les données en continu, les proxys absorbent les coupures WAN, et le serveur central maintient une vision cohérente de l’ensemble. Aucun service externe, aucune dépendance cloud : tout est local, maîtrisé, et auditable.
Avant de plonger dans les processus internes, il est utile d’avoir un schéma mental du pipeline Zabbix. Zabbix fonctionne comme une chaîne : collecte → prétraitement → insertion → agrégation → purge. Chaque étape a son propre processus, et c’est l’équilibre entre ces étapes qui détermine la stabilité du système.
2. Architecture interne : comprendre les processus clés
Zabbix Server fonctionne comme une chaîne de traitement continue. Chaque processus a une responsabilité précise, et c’est l’interaction entre ces briques qui donne au système sa fluidité. Lorsqu’on observe Zabbix en production, on comprend rapidement que ce ne sont pas les “fonctionnalités” qui définissent sa personnalité, mais la manière dont il orchestre la collecte, le prétraitement et l’écriture des données.
Pollers actifs et passifs
Les pollers interrogent les hôtes ou attendent leurs données. Leur saturation est un indicateur immédiat de sous‑dimensionnement : lorsque les pollers sont constamment occupés, les checks prennent du retard, les métriques perdent en fraîcheur, et la supervision commence à glisser.
Prenons par exemple : Une installation collecte 20 000 métriques toutes les 60 secondes. Les pollers tournent à 95 % d’occupation. Résultat : les checks SNMP prennent 3 à 5 secondes de plus que prévu, les alertes arrivent en décalé, et la supervision perd en précision.
Trappers
Les trappers reçoivent les données envoyées par les agents actifs, les scripts externes ou les proxys. Ils doivent absorber des flux parfois irréguliers. Lorsqu’ils saturent, Zabbix accumule du retard et les données arrivent en rafales.
Prenons par exemple : Un site distant perd sa connexion WAN pendant 12 minutes. Le proxy local continue de collecter les données, puis renvoie tout d’un coup lorsque le lien revient. Si les trappers ne sont pas dimensionnés pour absorber ce “burst”, la file monte à plusieurs milliers d’éléments.
Preprocessors
Les preprocessors nettoient, transforment et normalisent les données avant insertion. Lorsqu’ils prennent du retard, ce n’est pas seulement un problème de volume : c’est souvent le signe que les règles de transformation sont trop complexes ou que la cadence de collecte dépasse ce que le serveur peut absorber.
Prenons par exemple : Un item récupère un JSON de 50 Ko toutes les 10 secondes, puis applique 6 étapes de préprocessing. Résultat : la file explose, et tout le pipeline ralentit — alors que la métrique finale ne pèse que quelques octets.
History syncers
Les history syncers écrivent les données dans les tables d’historique. Leur charge dépend directement de la fréquence de collecte, du nombre d’items et de la performance du stockage. Lorsqu’ils n’arrivent plus à suivre, la base devient le goulot d’étranglement.
Prenons par exemple : Un serveur Zabbix installé sur un disque SATA doit absorber 200 000 écritures par minute. Les history syncers saturent, les temps d’insertion passent de 5 ms à 120 ms. Le simple passage à un SSD NVMe stabilise tout le système.
Escalations
Les escalations gèrent la logique d’alerting avancée. Elles ne consomment pas beaucoup de ressources, mais elles doivent rester cohérentes avec le modèle d’événements.
Prenons par exemple : Un trigger mal configuré génère un événement toutes les 30 secondes. L’escalation envoie une notification toutes les 60 secondes. Résultat : alertes en boucle, alors que le problème est déjà connu.
Housekeeper
Le housekeeper purge les données anciennes, gère les tendances et nettoie les événements expirés. Mal configuré, il peut devenir très gourmand en I/O.
Prenons par exemple : Une entreprise garde 365 jours d’historique détaillé pour 50 000 items. Le housekeeper doit purger plusieurs millions de lignes chaque nuit. Sur un stockage lent, cette opération peut durer des heures.
Cache interne
Le cache interne stocke temporairement des informations de configuration et des données fréquemment utilisées. Un cache trop petit entraîne une pression excessive sur la base.
Prenons par exemple : Un Zabbix avec 10 000 hôtes et 200 000 items tourne avec un cache de 128 Mo. Résultat : le cache se vide en permanence, et Zabbix sollicite la base pour des informations qu’il devrait garder en mémoire.
Une fois le pipeline interne compris, il devient plus simple de saisir comment Zabbix gère les erreurs, les timeouts et les événements. C’est un aspect souvent négligé, mais essentiel pour comprendre la stabilité du système.
3. Gestion des erreurs, timeouts et corrélation d’événements
Zabbix ne déclenche pas une alerte à chaque collecte. Il déclenche une alerte uniquement lorsqu’un état change. C’est un modèle événementiel, pas un modèle de polling naïf. Cela évite les alertes en rafale, mais impose une logique stricte dans la définition des triggers.
Lorsqu’un item échoue plusieurs fois, il passe en “unsupported”. Ce n’est pas une punition : c’est une protection. Zabbix préfère désactiver un item instable plutôt que de saturer les pollers avec des checks voués à l’échec.
Prenons par exemple : Un script externe met 12 secondes à répondre. Le timeout est à 10 secondes. Après plusieurs échecs, l’item passe en unsupported. Le poller est libéré, et le reste du système continue de fonctionner normalement.
Une fois qu’on comprend comment Zabbix gère les erreurs et les événements, il devient évident que le réseau joue un rôle essentiel dans la stabilité du système.
4. Impact réseau : agents actifs, agents passifs, proxys
Les agents actifs envoient les données au serveur ou au proxy. Les agents passifs attendent d’être interrogés.
Les actifs réduisent la charge sur les pollers, mais dépendent du DNS et de la connectivité. Les passifs sont plus simples à diagnostiquer, mais plus coûteux côté serveur.
Les proxys, eux, absorbent la latence et les coupures WAN. Ils sont indispensables dans les environnements distribués.
Prenons par exemple : Un site distant avec 200 agents passifs surcharge les pollers. En passant 80 % des agents en mode actif, la charge CPU du serveur chute de 25 %.
Et puisqu’on parle de stabilité, il faut aborder un sujet souvent mal compris : la haute disponibilité.
5. Haute disponibilité : ce que Zabbix protège… et ce qu’il ne protège pas
Zabbix HA existe, mais il ne protège que le serveur. La base SQL doit être HA séparément (PostgreSQL + Patroni, MySQL + Galera, etc.). Les proxys, eux, permettent à la supervision de continuer même si le serveur tombe.
Prenons par exemple : Le serveur Zabbix tombe pendant 20 minutes. Les proxys continuent de collecter les données. À la reprise, ils renvoient tout d’un bloc. La supervision n’a rien perdu.
Maintenant que tout le contexte est posé, on peut enfin parler de ce qui change réellement en 7.0 LTS — et surtout pourquoi ces changements comptent.
6. Nouveautés 7.0 LTS — Des améliorations qui répondent à de vrais problèmes
Zabbix 7.0 LTS n’est pas une version cosmétique. C’est une version qui corrige plusieurs limites structurelles des versions précédentes, en particulier 6.0 et 6.4, et qui améliore des composants qui étaient clairement perfectibles. Chaque nouveauté répond à un problème réel rencontré en production.
Agent2 : plus stable, plus modulaire, moins fragile
À partir de quoi ? L’agent classique était robuste mais monolithique, difficile à étendre, et parfois instable sur des environnements hétérogènes.
Qu’est‑ce qui a été amélioré ? L’agent2 repose sur une architecture modulaire en Go, avec un système de plugins propre et isolé.
Pourquoi c’est meilleur ?
- moins de crashs,
- meilleure gestion multi‑plateforme,
- plugins plus propres,
- performances plus stables.
Prenons par exemple : Sur un parc Windows avec 200 checks WMI, l’agent2 réduit la charge CPU de 20 à 30 %.
Preprocessing : plus rapide, plus propre, moins de backlog
À partir de quoi ? En 6.0/6.4, le préprocessing devenait un goulot d’étranglement dès qu’on manipulait du JSON volumineux ou des transformations complexes.
Qu’est‑ce qui a été amélioré ?
- meilleure parallélisation,
- gestion mémoire optimisée,
- exécution plus rapide des étapes lourdes.
Pourquoi c’est meilleur ?
- moins de files d’attente,
- moins de latence,
- meilleure absorption des pics.
Prenons par exemple : Un JSON de 50 Ko avec 5 étapes passe de 120 ms à 35 ms.
History syncers : meilleure absorption des écritures
À partir de quoi ? Les syncers étaient trop sensibles à la latence disque et aux batchs massifs.
Qu’est‑ce qui a été amélioré ?
- buffers optimisés,
- batchs plus efficaces,
- moins de locks SQL.
Pourquoi c’est meilleur ?
- moins de backlog,
- meilleure stabilité,
- meilleure tenue en charge.
Prenons par exemple : Sur 300 000 métriques/minute, les temps d’insertion passent de 80 ms à 25 ms.
Interface : plus fluide, moins de latence
À partir de quoi ? L’interface 6.4 était fonctionnelle mais parfois lente.
Qu’est‑ce qui a été amélioré ?
- rendu optimisé,
- cache mieux géré,
- requêtes SQL réduites.
Pourquoi c’est meilleur ?
- dashboards plus rapides,
- navigation plus fluide.
Prenons par exemple : Un dashboard de 20 widgets passe de 4,2 s à 1,8 s.
Environnements distribués : proxys plus robustes
À partir de quoi ? Les proxys géraient mal les bursts après une coupure WAN.
Qu’est‑ce qui a été amélioré ?
- meilleure gestion des bursts,
- synchronisation plus stable,
- moins de pertes.
Pourquoi c’est meilleur ?
- reprise plus propre,
- moins de surcharge sur les trappers.
Prenons par exemple : Un proxy offline 30 minutes renvoie 200 000 points. En 6.4 : 3 minutes de backlog. En 7.0 : 40 secondes.
Zabbix 7.0 LTS corrige beaucoup de choses, mais il ne change pas sa nature. Et c’est là que les limites structurelles apparaissent clairement.
7. Limites structurelles
Zabbix n’est pas conçu pour les métriques haute fréquence, les environnements Kubernetes massifs ou les pipelines cloud‑native. Son modèle SQL impose une limite naturelle à la volumétrie. Ce n’est pas un défaut : c’est un choix architectural.
Prenons par exemple : Une équipe tente de collecter des métriques toutes les 1 seconde sur 10 000 items. Résultat : la base sature, les history syncers prennent du retard, et la supervision devient inutilisable. Zabbix n’est pas fait pour ça — et il ne prétend pas l’être.
On ne maîtrise pas Zabbix en apprenant à créer des items. On le maîtrise en comprenant son fonctionnement interne : la façon dont il collecte, transforme et stocke les données, le rôle de ses processus, l’importance de la base SQL et des proxys, et les limites structurelles qui façonnent son comportement.