La plupart des déploiements Zabbix ratés ne le sont pas à cause d’un mauvais outil, mais d’une architecture mal pensée dès le départ — souvent parce que le rôle de chaque composant n’était pas clair avant de commencer. Voici les trois briques et quand utiliser chacune.
Le Zabbix Server : le cerveau, unique
Le serveur centralise la configuration, traite les données, évalue les triggers et déclenche les actions (alertes, scripts). Il n’y en a qu’un par installation (hors configuration haute disponibilité, qui reste une variante du même rôle). Toute la logique métier de la supervision y réside : c’est lui qui décide qu’une valeur dépasse un seuil et qu’il faut agir.
Erreur fréquente : sous-dimensionner le serveur ou sa base de données en pensant à la taille actuelle de l’infrastructure, sans anticiper la croissance. Le nombre de valeurs traitées par seconde (NVPS) est le vrai indicateur de charge — pas le nombre d’hôtes.
Le Zabbix Proxy : l’intermédiaire pour les sites distants
Un proxy collecte les données localement sur un site distant, les met en tampon, puis les transmet au serveur central. Il devient indispensable dès que l’infrastructure s’étend sur plusieurs sites géographiques, ou quand une liaison réseau vers le serveur central n’est pas fiable à 100 %.
Deux bénéfices concrets : la collecte continue même si la liaison vers le serveur central est temporairement coupée (le proxy stocke localement et transmet dès que la liaison revient), et une réduction significative de la charge réseau et CPU sur le serveur central, puisque le proxy pré-traite une partie du travail.
Erreur fréquente : déployer un serveur Zabbix unique interrogeant directement des centaines d’équipements sur plusieurs sites distants sans proxy — ça fonctionne un temps, puis la latence réseau et les coupures ponctuelles commencent à créer des trous dans l’historique.
L’Agent Zabbix : la sonde sur chaque machine
L’agent s’installe sur les machines à surveiller (Linux, Windows) et remonte des métriques locales — CPU, mémoire, disque, processus, logs. Il existe en deux modes : passif (le serveur ou le proxy interroge l’agent à intervalle régulier) et actif (l’agent envoie lui-même les données, plus adapté aux environnements avec beaucoup d’hôtes ou des contraintes réseau spécifiques, comme les équipements mobiles ou le cloud).
Pour les équipements qui ne supportent pas d’agent (switchs, routeurs, imprimantes réseau), Zabbix interroge directement via SNMP, IPMI ou des checks réseau simples — sans rien installer sur l’équipement lui-même.
Une architecture type, pour fixer les idées
- Un seul site, moins de 200 hôtes : un serveur Zabbix suffit, agents en mode passif ou actif selon le contexte, pas de proxy nécessaire.
- Plusieurs sites, ou plus de 500 hôtes : un serveur central + un proxy par site distant, agents en mode actif pour réduire la charge du proxy.
- Infrastructure critique, haute disponibilité requise : serveur en cluster HA natif, base de données répliquée, proxies redondants sur les sites les plus sensibles.
Pour aller plus loin : Erreurs à éviter en production · Zabbix haute disponibilité
Le dimensionnement se pense avant le premier agent installé, pas après le premier ralentissement constaté. Une architecture correcte dès le départ évite une migration douloureuse six mois plus tard.