⚠️ Préambule indispensable : SQLite, un choix par défaut… mais rarement un bon choix
Zabbix propose SQLite par défaut pour la base locale du proxy. C’est simple et léger, utile pour des proxys de test ou très petits sites. Mais SQLite est un moteur embarqué reposant sur un fichier unique, sans authentification, sans concurrence réelle et avec un verrou global d’écriture. Dans des contextes pro (volumétrie élevée, WAN instable, MSP, DMZ, sites industriels), ces limites deviennent un point faible capable de dégrader l’ensemble du pipeline de collecte. Pour tout proxy en production dépassant quelques milliers d’items ou soumis à coupures réseau, PostgreSQL est la seule option sérieuse : écritures concurrentes, WAL, partitionnement, sécurité et maintenance.
1. Le rôle réel du proxy : collecter, tamponner, synchroniser
Le proxy n’est pas un mini‑serveur d’alerting : il exécute les checks localement, tamponne les données, puis synchronise. Il absorbe la latence WAN, protège le serveur central des bursts, isole les environnements (DMZ, MSP) et stabilise le pipeline de collecte.
2. Pourquoi le proxy est indispensable (réseau + infra)
- Absorber la latence WAN : exécution locale des checks → latence WAN limitée à la synchronisation.
- Protéger le serveur : tamponner les bursts et envoyer un flux régulier.
- Isoler les environnements : réduire les ouvertures firewall et centraliser un seul flux sortant par site/client.
Prenons par exemple : un site distant avec 80 ms de latence et 12k checks/min : sans proxy, les pollers centraux saturent ; avec proxy local, la collecte reste régulière et seule la synchronisation transite par le WAN.
3. Architecture interne du proxy — pipeline détaillé
Vue d’ensemble : réception (trappers) → collecte active (pollers) → prétraitement (preprocessors) → écriture locale (history syncers) → buffer & sync → envoi au serveur. Chaque étape a sa file, ses métriques et ses points de blocage.
Où regarder :
- métriques internes :
zabbix[proxy,poller,avg,busy],zabbix[proxy,trapper,avg,busy],zabbix[proxy,preprocessing,queue],zabbix[proxy,history,syncers,busy],zabbix[proxy,queue],zabbix[proxy,lastaccess],zabbix[proxy,values,processed]. - logs proxy : “database is locked”, “queue is full”, “cannot connect to server”, “preprocessing failed”.
- frontend : décalage des Latest data, timestamps incohérents.
Points de friction : files qui s’allongent, verrous DB (SQLite), bursts réseau au flush, fragmentation MTU, CPU saturé sur preprocessors.
4. Pollers — mécanique, diagnostic, remédiation
Mécanique : un poller exécute un check à la fois ; checks bloquants (SNMP, scripts) monopolisent le poller. Signes : poller busy % élevé (>60–70 %), décalage d’intervalles, logs timeouts. Paramètres : StartPollers, Timeout, UnreachableDelay. Diagnostic : lire zabbix[proxy,poller,avg,busy], mesurer CPU/I/O, lister checks longs, tester latence réseau (ping/mtr). Actions : augmenter StartPollers par paliers, réduire timeouts non critiques, déplacer checks lourds vers proxy dédié, optimiser scripts.
Prenons par exemple : 9k checks/min avec 4 pollers → busy 100 %. Augmenter à 12 pollers restaure les intervalles ; si CPU reste élevé, déplacer ou optimiser checks.
5. Trappers — réception, fragmentation, MTU
Mécanique : trappers acceptent connexions TCP des agents ; payloads volumineux (JSON, lots) peuvent fragmenter. Signes : trapper busy % élevé, logs “connection reset”, retransmissions TCP. Paramètres : StartTrappers, HeartbeatFrequency, buffers locaux. Diagnostic réseau : PMTU (tracepath), retransmissions (ss -s), fragmentation observée. Actions : augmenter StartTrappers, réduire batchs côté agent, corriger MTU/MSS, ajuster timeouts firewall.
Prenons par exemple : agents envoient gros payloads via VPN MTU réduit → fragmentation → reconnections ; solution : réduire batchs ou corriger MTU.
6. Preprocessors — coût CPU et bonnes pratiques
Mécanique : JSONPath, regex, conversions ; chaque transformation consomme CPU. Signes : preprocessing queue qui monte, CPU élevé, erreurs regex. Paramètres : StartPreprocessors, cache/mémoire proxy. Diagnostic : identifier templates lourds, profiler CPU. Actions : simplifier regex, privilégier JSONPath ciblé, réduire fréquence, augmenter threads si CPU disponible, externaliser transformations lourdes.
Prenons par exemple : flux IoT avec JSON profond et 50 transformations → CPU saturé ; réduire transformations essentielles et préfiltrer côté device résout le problème.
7. History syncers & base locale — SQLite vs PostgreSQL (approfondi)
Mécanique : syncers écrivent en local ; débit dépend du moteur DB et du stockage. SQLite : verrou global, une écriture à la fois, risque de corruption sur crash, pas de sécurité native — adapté uniquement pour proxys très légers (<10–20k métriques/min). PostgreSQL : écritures concurrentes, WAL, partitionnement, sécurité, maintenance — recommandé en production. Signes DB : logs “database is locked”, latence d’écriture, backlog permanent. Diagnostic stockage : IOPS et latence (iostat, fio), contention fichier SQLite, taille tables. Actions : migrer vers PostgreSQL local pour proxys >20k items, SSD/NVMe pour IOPS, augmenter syncers si DB et I/O le permettent, partitionner tables côté PostgreSQL.
Prenons par exemple : proxy SQLite accumule backlog après coupure WAN de 30 min ; migration vers PostgreSQL NVMe vide la queue en quelques minutes.
8. Buffering, offline mode, flush — réseau, MTU, jitter, bursts
Mécanique : proxy tamponne et renvoie par lots ; la cadence et la taille des lots dépendent de config et réseau. Risques réseau : MTU faible → fragmentation → retransmissions ; jitter/perte → ré‑essais TCP ; firewalls stateful coupant connexions longues. Diagnostic : PMTU, mtr pour perte/jitter, iperf pour bande passante, ss -s pour retransmissions. Actions : ajuster DataSenderFrequency/batch size, corriger MTU/MSS sur tunnels, appliquer QoS, réduire taille des paquets envoyés, lisser l’envoi.
Prenons par exemple : après 25 min de coupure, proxy renvoie 200k lignes via VPN MTU réduit → fragmentation et retransmissions ; réduire batchs et corriger MTU stabilise le flush.
9. Diagnostics avancés et playbook d’investigation
Checklist d’investigation
- Vérifier métriques internes (poller/trapper/preprocessing/history busy %, queue, lastaccess).
- Consulter logs proxy (DB locked, queue full, cannot connect).
- Mesurer infra (CPU, RAM, IOPS, latence disque).
- Tester réseau (ping, mtr, iperf, PMTU).
- Vérifier DB (SQLite vs Postgres, latence d’écriture).
- Analyser templates (items lourds, preprocessors, scripts).
- Simuler charge contrôlée.
Remédiations standard
- poller busy → augmenter
StartPollers, optimiser checks, répartir. - trapper busy → augmenter
StartTrappers, réduire payloads, corriger MTU. - preprocessing queue → simplifier transformations, augmenter threads si CPU.
- history syncer busy → migrer SQLite→Postgres, améliorer stockage.
- flush chaotique → réduire batch size, ajuster DataSenderFrequency, corriger réseau.
Outils réseau : ping, mtr, iperf, tracepath/mturoute, ss -s, logs firewall.
Prenons par exemple : poller busy 90 % + history syncer busy 80 % → checks SNMP lourds + stockage lent ; solution : augmenter pollers, migrer DB sur SSD, déplacer checks non critiques.
10. Monitoring et seuils recommandés (items & triggers prêts)
Items Zabbix à déployer
zabbix[proxy,poller,avg,busy]— trigger > 70 % (warning), > 90 % (critique).zabbix[proxy,trapper,avg,busy]— trigger > 70 %.zabbix[proxy,preprocessing,queue]— trigger si > 1000.zabbix[proxy,history,syncers,busy]— trigger > 60 %.zabbix[proxy,queue]— trigger si croissance continue > 5 min.zabbix[proxy,lastaccess]— trigger si > 3× heartbeat.- DB I/O latency (custom) — trigger si latence écriture > 10 ms (SSD) / >50 ms (HDD).
Playbook d’alerte rapide
- alerte poller busy → vérifier CPU, augmenter pollers, lister checks longs.
- alerte trapper busy → vérifier MTU, augmenter trappers, réduire batchs agents.
- alerte history syncer busy → vérifier DB type, latence I/O, migrer si nécessaire.
11. Dimensionnement et recommandations matérielles
Règles empiriques
- Petits proxys (<20k items) : SQLite acceptable, 2–4 vCPU, 4–8 GB RAM, SSD.
- Moyens (20k–100k) : PostgreSQL recommandé, 4–8 vCPU, 8–16 GB RAM, NVMe, IOPS 5k+.
- Gros (>100k) : PostgreSQL local, 8+ vCPU, 16–64 GB RAM, NVMe RAID, stockage dimensionné pour latence <5 ms.
Ratios indicatifs
- 1 poller pour 5–10k checks/minute (ajuster selon type de checks).
- 1 trapper pour 5–10k métriques/minute en flux continu.
- syncers : tester et augmenter jusqu’à saturation I/O.
Réseau
- garantir bande passante pour flushs ; prioriser Zabbix si possible.
- corriger MTU/MSS sur VPN/IPsec ; éviter NATs complexes pour agents→proxy.
Prenons par exemple : proxy pour 150k métriques/min → PostgreSQL local NVMe, 12 vCPU, 32 GB RAM, 6 syncers, pollers/trappers dimensionnés par tests de charge.
12. Pièges avancés et recommandations finales
Pièges fréquents : confondre latence réseau et saturation DB ; laisser SQLite sur proxys surchargés ; ignorer MTU/VPN ; multiplier scripts lents sur même proxy. Recommandations : mesurer avant d’ajuster, tester en staging, prévoir proxys dédiés pour charges lourdes, documenter la répartition hôtes→proxys, automatiser déploiement/configuration.
Playbook imprimable — checklist opérationnelle
Surveillance initiale (à déployer sur serveur central)
- Items listés en §10.
- Triggers : poller/trapper busy (70/90), queue growth > 5 min, lastaccess > 3× heartbeat, DB write latency thresholds.
Diagnostic rapide (en cas d’alerte)
- Vérifier métriques internes.
- Consulter logs proxy.
- Mesurer CPU/I/O.
- Tester réseau (ping/mtr/iperf).
- Vérifier DB (SQLite lock / Postgres latency).
- Appliquer remédiation ciblée (augmenter threads, réduire batchs, migrer DB).
Actions correctives prioritaires
- augmenter
StartPollers/StartTrappers/StartPreprocessorspar paliers ; observer 15–30 min. - réduire fréquence/timeout des checks non critiques.
- corriger MTU/MSS sur tunnels.
- migrer SQLite→PostgreSQL si backlog persistant.
- dimensionner stockage (NVMe) si IOPS insuffisantes.