Après avoir vu comment Zabbix collecte, transforme et stocke les données, la suite logique consiste à comprendre comment l’installer correctement. Une installation Zabbix n’est pas un simple déploiement logiciel : c’est la fondation d’un pipeline qui devra absorber des milliers de points de données par minute, rester stable sous charge, et fonctionner sans dette technique. Une architecture mal posée crée des problèmes que même la meilleure optimisation ne rattrapera pas. Une architecture propre, elle, reste stable, prévisible et durable.
1. Architecture recommandée : mono‑nœud, multi‑nœud, proxys
Zabbix peut être installé de plusieurs manières, mais seules trois architectures sont réellement pertinentes. Le choix dépend de la volumétrie, de la topologie réseau et du niveau d’isolation souhaité.
Architecture mono‑nœud : simple, efficace, mais limitée
Un seul serveur Zabbix, une seule base SQL, aucun proxy. C’est l’architecture la plus simple, parfaitement adaptée aux petites infrastructures homogènes.
Elle fonctionne bien lorsque :
- le parc est inférieur à 300–500 hôtes,
- la collecte n’est pas trop fréquente,
- tout est sur un même site,
- la latence réseau est faible.
Prenons par exemple : Une PME avec 200 postes et 30 serveurs déploie Zabbix sur une VM dédiée avec PostgreSQL local. Le stockage NVMe absorbe facilement les écritures générées par les history syncers — les processus qui écrivent les données brutes dans la base. Comme le disque suit le rythme, aucun backlog ne se forme, et le pipeline reste fluide même lors des pics d’activité.
Architecture multi‑nœud : Zabbix + base SQL séparée
Dès que la volumétrie augmente, il devient indispensable de séparer Zabbix Server et la base SQL. Ce n’est pas une optimisation : c’est une nécessité structurelle.
Avantages :
- meilleure performance,
- meilleure isolation,
- maintenance plus simple,
- possibilité de mettre la base en haute disponibilité.
Prenons par exemple : Une entreprise avec 800 hôtes et 150 000 items sépare Zabbix Server (CPU/RAM) et PostgreSQL (NVMe dédié). La base absorbe les écritures sans latence, ce qui empêche les history syncers de s’accumuler. Le serveur reste réactif, même lorsque les preprocessors — les processus qui transforment les données avant insertion — manipulent des JSON volumineux.
Architecture distribuée : les proxys comme colonne vertébrale
Dès qu’il y a plusieurs sites, plusieurs zones réseau, ou plusieurs clients, les proxys deviennent indispensables. Un proxy Zabbix est un collecteur autonome : il exécute les checks, stocke temporairement les données dans sa propre base locale, puis les renvoie au serveur central.
Il absorbe la latence, tamponne les coupures, et réduit la charge sur le serveur principal.
Prenons par exemple : Un groupe avec 12 agences réparties en France place un proxy dans chaque agence. Lorsqu’une liaison WAN tombe, le proxy continue de collecter localement. À la reprise, il renvoie les données progressivement, ce qui évite de saturer les trappers — les processus du serveur qui reçoivent les données entrantes. Résultat : aucune perte de données et aucune surcharge.
2. PostgreSQL optimisé : buffers, autovacuum, partitionnement
Zabbix repose sur PostgreSQL pour une raison simple : c’est le moteur SQL qui encaisse le mieux les écritures massives. Mais PostgreSQL doit être configuré correctement. Une base mal réglée peut ruiner une installation parfaite.
Buffers : la RAM comme amortisseur
Le paramètre shared_buffers détermine la quantité de RAM utilisée pour stocker temporairement les données avant écriture. Trop petit → PostgreSQL lit et écrit en permanence sur disque. Trop grand → la mémoire est gaspillée.
Prenons par exemple : Un serveur PostgreSQL avec 32 Go de RAM passe shared_buffers de 1 Go à 8 Go. Les lectures disque diminuent drastiquement, ce qui réduit la latence d’insertion. Les history syncers n’attendent plus, et le pipeline reste stable même lors des pics de collecte.
Autovacuum : indispensable, mais à dompter
PostgreSQL utilise un mécanisme interne appelé autovacuum — un processus automatique qui nettoie les tables et supprime les données obsolètes. Mais sur les tables Zabbix (history, trends), il doit être ajusté.
Les bonnes pratiques :
- augmenter
autovacuum_vacuum_cost_limit, - réduire
autovacuum_vacuum_scale_factor, - activer l’autovacuum agressif sur les tables volumineuses.
Prenons par exemple : Une base avec 200 millions de lignes dans history_uint commence à ralentir. Le bloat augmente, les requêtes deviennent plus lourdes, et les history syncers prennent du retard. En activant un autovacuum agressif, la table reste compacte, les index restent efficaces, et la latence SQL redevient stable.
Partitionnement : obligatoire au‑delà d’un certain volume
Les tables history et trends doivent être partitionnées. Sans partitionnement, les purges deviennent lentes, et le housekeeper — le processus qui supprime les données anciennes — souffre.
Prenons par exemple : Une installation de 500 000 métriques/minute purge plusieurs millions de lignes par jour. Sans partitionnement, le housekeeper doit parcourir des tables gigantesques, ce qui bloque la base pendant de longues minutes. Avec le partitionnement, la purge se résume à supprimer une partition entière : une opération quasi instantanée.
3. Choix du serveur : bare‑metal, VM, container
Zabbix peut tourner partout, mais pas n’importe comment.
Bare‑metal : la performance brute
Idéal pour les très grosses installations. Avantages :
- I/O maximales,
- latence minimale,
- stabilité.
Inconvénients :
- moins flexible,
- maintenance plus lourde.
VM : le meilleur compromis
C’est le choix recommandé dans 80 % des cas. Une VM dédiée, avec CPU réservés et stockage NVMe, suffit largement.
Prenons par exemple : Une VM 8 vCPU / 16 Go RAM / NVMe local encaisse 200 000 métriques/minute. Le NVMe absorbe les écritures sans latence, ce qui empêche les history syncers de s’accumuler. Le serveur reste réactif, même lorsque les preprocessors manipulent des données lourdes.
Containers : à manier avec précaution
Zabbix en container fonctionne… mais demande une architecture maîtrisée. Les problèmes classiques :
- stockage lent,
- réseau overlay,
- ressources partagées,
- logs difficiles à diagnostiquer.
C’est viable, mais pas pour tout le monde.
4. Zabbix Server vs Zabbix Proxy : rôles, implications, pièges
Le serveur est le cerveau. Le proxy est le collecteur.
Le piège classique : croire qu’un proxy est un “serveur secondaire”. Non. Un proxy ne fait pas d’alerting, pas de corrélation, pas d’escalation. Il collecte, tamponne, et renvoie.
Quand utiliser un proxy ?
- plusieurs sites,
- latence WAN,
- environnements isolés,
- clients multiples,
- besoin de scaling horizontal.
Pièges classiques
- mettre trop d’items sur un proxy SQLite,
- sous‑dimensionner le disque,
- oublier que le proxy peut saturer avant le serveur.
Prenons par exemple : Un proxy SQLite — c’est‑à‑dire un proxy utilisant une base locale très légère — commence à saturer dès qu’on dépasse quelques dizaines de milliers d’items. SQLite n’est pas conçu pour absorber autant d’écritures simultanées, ce qui crée un backlog local. En migrant vers PostgreSQL local, le proxy absorbe les écritures sans latence, et la synchronisation avec le serveur redevient fluide.
5. Agent vs Agent2 : différences, cas d’usage
L’agent classique est stable, mais limité. L’agent2 — la nouvelle génération d’agent Zabbix, écrite en Go et basée sur un système de plugins — est plus modulaire et plus stable.
Quand utiliser l’agent classique ?
- environnements très anciens,
- compatibilité maximale,
- scripts existants.
Quand utiliser l’agent2 ?
- environnements modernes,
- besoin de plugins,
- collectes complexes,
- Windows intensif.
Prenons par exemple : Un parc Windows utilise 200 checks WMI. L’agent classique surcharge le CPU, car chaque collecte WMI est coûteuse. L’agent2, mieux optimisé et plus moderne, réduit cette charge de 20 à 30 %, ce qui stabilise les postes et améliore la fraîcheur des données.
6. Sécurité : TLS, segmentation réseau, gestion des secrets
Zabbix n’est pas un outil à exposer. Il doit être isolé, segmenté, et chiffré.
TLS partout
- agents → serveur/proxy
- proxys → serveur
- API → interface
C’est simple à activer, et indispensable.
Segmentation réseau
Zabbix doit être dans un VLAN dédié. Les agents ne doivent pas accéder à l’interface. Les proxys ne doivent pas accéder à la base.
Gestion des secrets
- pas de mots de passe en clair dans les scripts,
- utiliser les macros sécurisées,
- limiter les droits SQL.
Prenons par exemple : Un script externe contient un mot de passe root MySQL. Lorsqu’un agent est compromis, l’attaquant remonte jusqu’au serveur. En utilisant les macros sécurisées, le secret n’est jamais exposé en clair, ce qui supprime ce vecteur d’attaque.
7. Monitoring du monitoring : Zabbix qui se supervise lui‑même
Un Zabbix non supervisé est un Zabbix qui tombera un jour sans prévenir.
À surveiller absolument :
- poller busy % — charge des pollers, les processus qui exécutent les checks,
- trapper queue — file d’attente des données entrantes,
- preprocessing queue — file d’attente des transformations,
- history syncers — charge d’écriture SQL,
- latence SQL,
- espace disque,
- housekeeper runtime.
Prenons par exemple : Un poller busy à 90 % pendant 10 minutes indique que les checks prennent du retard. Si personne ne surveille cet indicateur, la supervision devient progressivement aveugle. Une alerte sur ce seuil permet d’intervenir avant que le pipeline ne sature.
8. Pièges classiques à éviter
- installer Zabbix sur un disque lent,
- ignorer les proxys,
- laisser MySQL par défaut,
- ne pas partitionner,
- mettre trop d’items sur un proxy SQLite,
- ne pas surveiller Zabbix lui‑même,
- utiliser des agents passifs partout,
- laisser l’autovacuum par défaut.
Prenons par exemple : Une installation de 100 000 items tourne sur MySQL non optimisé. Tout fonctionne… jusqu’au jour où le housekeeper purge 20 millions de lignes. La base se bloque pendant 45 minutes, les history syncers s’accumulent, et la supervision devient inutilisable. Une configuration SQL correcte aurait évité ce scénario.
Une installation Zabbix fiable repose sur des choix structurants : stockage rapide, base SQL optimisée, proxys bien positionnés et agents correctement configurés. Lorsque ces éléments sont maîtrisés, le serveur fonctionne sans contrainte et l’exploitation devient nettement plus simple. C’est ce cadre qui permet ensuite d’aborder la supervision distribuée de manière propre.