Zabbix en production : architecture interne, tuning, diagnostics et limites structurelles

Préambule — La production n’est pas un laboratoire

Exploiter Zabbix en production exige de passer d’une vision logicielle à une vision systémique. Un serveur sous charge est un écosystème où chaque composant — pollers, preprocessors, syncers, base SQL — influence la stabilité globale.

La règle est ici souveraine : Mesurer → Formuler une hypothèse → Modifier par paliers → Observer → Documenter. Il s’agit de dissèquer les engrenages internes et fournir les procédures exactes pour chaque levier d’optimisation.

---

1. Pollers — La gestion de l’attente

1.1 La mécanique du blocage

Un poller est un séquenceur bloquant. S’il interroge un équipement lent, il reste figé jusqu’au Timeout. Si la file d’attente s’allonge, les données « glissent » (dérive des intervalles).

1.2 Comment diagnostiquer

1. Surveillance visuelle : Allez dans Administration > Queue > Overview by proxy. Si la colonne « 5 seconds » ou « 10 seconds » est rouge, vos pollers sont saturés.

2. Métriques internes : Créez un graphique avec l’item zabbix[process,poller,avg,busy].

   • Busy > 75% : Danger imminent.

   • Busy à 100% avec CPU bas : Latence réseau (Timeouts).

   • Busy à 100% avec CPU haut : Surcharge de calcul.

1.3 Comment procéder au tuning

• Accès : Éditez /etc/zabbix/zabbix_server.conf.

• Levier 1 : Augmentez StartPollers par paliers de 10% à 20%.

• Levier 2 : Réduisez le paramètre Timeout (souvent 3s par défaut) à 1s ou 2s pour libérer les pollers plus vite.

• Relance : systemctl restart zabbix-server.

---

2. Preprocessors — Le goulot invisible

2.1 La dualité Manager / Workers

Le Manager reçoit les données des pollers et les distribue aux Workers. Le goulot peut être le Manager (trop de petites données) ou les Workers (calculs trop lourds).

2.2 Comment diagnostiquer

1. Métriques internes : Surveillez zabbix[process,preprocessing manager,avg,busy] et zabbix[process,preprocessing worker,avg,busy].

2. Files d’attente : Regardez l’item zabbix[preprocessing_queue]. Si elle ne redescend jamais à zéro, votre chaîne de traitement est sous-dimensionnée.

2.3 Comment procéder au tuning

• Accès : /etc/zabbix/zabbix_server.conf.

• Levier : Augmentez StartPreprocessors.

• Optimisation : Dans l’interface, identifiez les templates utilisant massivement des Regex ou du JavaScript. Remplacez-les par des étapes « JSONPath » ou « Custom multiplier » (plus économes en CPU).

---

3. History Syncers — La persistance sous pression

3.1 Le flux vers la base SQL

Les Syncers vident le Value Cache vers la base SQL. Si la base ralentit, les Syncers saturent et la collecte s’arrête pour éviter la perte de données en RAM.

3.2 Comment diagnostiquer

1. Saturation du cache : Surveillez zabbix[wcache,value,pused]. Si vous approchez de 100%, le serveur va cesser de collecter.

2. Activité des syncers : Surveillez zabbix[process,history syncer,avg,busy].

3.3 Comment procéder au tuning

• Accès : /etc/zabbix/zabbix_server.conf.

• Levier 1 : HistoryCacheSize. Ne pas hésiter à passer à 128M ou 256M pour absorber les pics.

• Levier 2 : StartDBSyncers. Attention : Ne dépassez jamais 32 sans une infrastructure SQL exceptionnelle, au risque de créer des verrous (deadlocks).

• Stockage : Vérifiez les IOPS avec iostat -x 1. Si %util est à 100%, le problème est matériel (disque).

---

4. La Base SQL — Le pivot central

4.1 Indexation et Slow Queries

Un index accélère la lecture (Dashboards) mais ralentit l’écriture (Syncers).

4.2 Comment diagnostiquer

1. PostgreSQL : Installez l’extension pg_stat_statements et exécutez : SELECT query, calls, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

2. Zabbix Logs : Activez temporairement DebugLevel=3 et cherchez « slow query ».

4.3 Comment procéder au tuning (Partitionnement)

• Accès : SQL Shell (psql ou mysql).

• Procédure : N’utilisez plus le Housekeeper natif (HousekeepingFrequency=0 dans la conf).

• Outil : Installez pg_partman pour PostgreSQL. Créez des partitions quotidiennes pour les tables history* et trends*.

• Bénéfice : Le nettoyage se fera par un DROP TABLE programmé, supprimant des Go de données en une fraction de seconde sans impacter les syncers.

---

5. Optimisation des Agents — Scalabilité à la source

5.1 Agents Actifs : La clé du succès

En mode Actif, l’agent demande sa configuration au serveur puis pousse ses données. Le serveur devient un simple récepteur passif.

5.2 Comment procéder

1. Configuration Agent : Dans zabbix_agentd.conf, réglez StartAgents=0 (pour désactiver le mode passif) et configurez ServerActive=IP_DU_SERVEUR.

2. Interface Zabbix : Changez le « Type » de tous vos items en « Zabbix agent (active) ».

3. Surveillance : Surveillez zabbix[process,trapper,avg,busy] sur le serveur pour voir la charge de réception des agents actifs.

---

6. Diagnostics avancés — L’outil de dernier recours

6.1 Le Runtime Control

Lorsque le serveur semble « figé », utilisez la commande de diagnostic en temps réel.

• Commande : zabbix_server -R diag

• Accès aux résultats : tail -f /var/log/zabbix/zabbix_server.log

• Interprétation : Le dump affichera l’utilisation précise de chaque « Shared Memory Statistics ». C’est ici que vous verrez si le goulot est le ValueCache, le LLD cache ou le Write cache.

---

7. Limites structurelles — Savoir quand s’arrêter

7.1 Ingestion massive

Zabbix n’est pas une base de données de séries temporelles (TSDB) pure.

• Diagnostic : Si votre NVPS (New Values Per Second) dépasse 15 000-20 000, le moteur SQL traditionnel (même tuné) commencera à souffrir.

• Action : Migrez vers TimescaleDB (extension PostgreSQL). Activez l’option de compression native dans Zabbix pour réduire l’empreinte disque de 90%.

---

La performance de Zabbix ne se décrète pas, elle se construit. En accédant aux fichiers de configuration avec une méthodologie de mesure (zabbix[process,...]), vous quittez le monde du tâtonnement pour celui de l’ingénierie. Gardez vos syncers fluides, vos preprocessors légers et votre SQL partitionné : c’est la seule recette pour un monitoring qui ne s’effondre pas lors du prochain incident majeur.