📍 Lecture connexe : Zabbix 7 LTS en 2026 : supervision open-source en production — pour la vue d’ensemble et les arbitrages.
Superviser des hôtes derrière un firewall ou dans une agence distante via une connexion ADSL pose deux problèmes : ouvrir le port 10050 entrant côté agence est rarement souhaitable, et la collecte directe encaisse mal les coupures réseau. Le Zabbix Proxy résout les deux : un proxy déployé localement collecte les hôtes de son site, bufferise pendant les coupures, et pousse vers le serveur central via une connexion sortante chiffrée. Ce tutoriel monte un proxy de zéro, l’enregistre auprès du serveur, déplace des hôtes derrière lui, et explore les modes actif et passif.
Prérequis
- Une instance Zabbix 7 fonctionnelle accessible depuis le futur proxy (port 10051 ouvert entrant)
- Une seconde machine Linux (Debian 12 / Ubuntu 24.04) qui hébergera le proxy
- Idéalement quelques hôtes côté distant déjà supervisés directement par le serveur central
- Niveau attendu : intermédiaire
- Temps estimé : environ 60 minutes
Étape 1 — Comprendre les modes actif et passif du proxy
Le proxy Zabbix peut tourner dans deux modes. En active mode, le proxy se connecte au serveur central (port 10051 sortant) à intervalle régulier, demande la configuration des hôtes qu’il doit superviser, collecte localement, puis pousse les valeurs au serveur. C’est le mode recommandé en 2026 : il ne demande aucun port entrant ouvert sur le proxy, ce qui simplifie la sécurité.
En passive mode, c’est l’inverse : le serveur central se connecte au proxy pour récupérer les données. Ce mode est rare en pratique, sauf cas spécifiques où le proxy est dans une zone réseau plus accessible que le serveur.
On retiendra le mode actif comme défaut. Tous les exemples qui suivent l’utilisent.
Étape 2 — Installer le proxy
Sur la machine qui sera le proxy, on ajoute le dépôt Zabbix (même paquet zabbix-release que pour le serveur, tutoriel d’installation), puis on installe le paquet proxy avec sa base SQLite.
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
sudo dpkg -i zabbix-release_latest_7.0+debian12_all.deb
sudo apt update
sudo apt install -y zabbix-proxy-sqlite3 zabbix-sql-scriptsLe choix de SQLite comme backend est volontaire : le proxy bufferise temporairement les données, il n’en fait pas un usage persistant long. SQLite tient parfaitement la charge pour quelques milliers d’items. Pour un proxy qui supervise des dizaines de milliers d’items, on bascule sur PostgreSQL ou MySQL avec le paquet correspondant.
Étape 3 — Configurer le proxy
Le fichier de configuration est /etc/zabbix/zabbix_proxy.conf. On édite trois directives clés. ProxyMode=0 pour le mode actif (1 pour passif). Server=10.0.0.10 avec l’IP du serveur central. Hostname=site-paris-proxy avec un nom unique pour ce proxy.
sudo sed -i 's/^# ProxyMode=.*/ProxyMode=0/' /etc/zabbix/zabbix_proxy.conf
sudo sed -i 's/^Server=.*/Server=10.0.0.10/' /etc/zabbix/zabbix_proxy.conf
sudo sed -i 's/^Hostname=.*/Hostname=site-paris-proxy/' /etc/zabbix/zabbix_proxy.conf
sudo systemctl enable zabbix-proxy
sudo systemctl start zabbix-proxyLe service démarre, crée la base SQLite, et tente de se connecter au serveur central. Si les credentials et l’IP sont corrects, le serveur va voir un nouveau proxy s’enregistrer mais refusera tant que le proxy n’est pas déclaré côté frontend (par sécurité).
Étape 4 — Déclarer le proxy côté frontend
Sur le frontend Zabbix, on va dans Administration → Proxies → Create proxy. Proxy name site-paris-proxy (identique au Hostname côté config), Proxy mode Active, Description libre. On valide.
Le proxy apparaît dans la liste avec un statut. Au début, le statut est « unknown » ; après quelques minutes, il bascule en « online » si la communication fonctionne. Si le statut reste rouge avec « cannot connect to proxy », c’est que le firewall bloque le 10051 entrant côté serveur central.
On peut consulter les logs du proxy pour diagnostiquer : sudo tail -f /var/log/zabbix/zabbix_proxy.log. Au démarrage, on voit « Starting Zabbix Proxy » suivi de tentatives de connexion vers le serveur. Toute ligne ERROR sur la première heure indique un problème à résoudre.
Étape 5 — Déplacer un hôte derrière le proxy
Une fois le proxy actif, on déplace les hôtes du site distant. Configuration → Hosts → cocher les hôtes du site → Mass update → onglet Host → Monitored by proxy → site-paris-proxy → Update.
Chaque hôte concerné voit son champ « Monitored by » passer du serveur au proxy. À la prochaine synchronisation (typiquement 30 secondes), la configuration est poussée au proxy qui prend le relais. Les agents des hôtes n’ont rien à modifier — le proxy se présente à eux comme s’il était le serveur.
Subtilité importante : si les agents des hôtes étaient configurés en mode active (poussant vers le serveur central via ServerActive=10.0.0.10), il faut maintenant qu’ils pointent vers le proxy : ServerActive=192.168.1.10 (IP du proxy). Sinon les checks actifs continuent d’aller au serveur central et le proxy ne reçoit rien.
Étape 6 — Vérifier que les métriques arrivent via le proxy
Dans Monitoring → Hosts → l’hôte qu’on a déplacé, on regarde Latest data. Les métriques continuent d’arriver, ce qui prouve que la chaîne agent → proxy → serveur fonctionne. Pour confirmer le passage par le proxy, on consulte le panneau de statistiques du proxy : Reports → Server info → Proxies. Le proxy doit afficher un nombre d’hôtes supervisés, un volume NVPS et un statut de queue.
Les logs du proxy montrent l’activité : « received configuration data from server », « sent N values to server ». Une queue qui grossit sans descendre indique que le proxy ne pousse pas assez vite ; on augmente alors ConfigFrequency et DataSenderFrequency.
Étape 7 — Comprendre le buffering en cas de coupure
Le proxy bufferise les données dans sa base locale quand la connexion vers le serveur central tombe. Cette résilience est l’une des raisons principales de déployer un proxy plutôt que de connecter les agents directement.
Pour tester : on coupe le réseau entre le proxy et le serveur (par exemple via iptables -A OUTPUT -d 10.0.0.10 -j DROP sur le proxy). On vérifie que les agents continuent de pousser vers le proxy, qui les stocke localement. On rétablit la connexion ; le proxy détecte la reprise et déverse son backlog vers le serveur dans l’ordre chronologique.
La capacité de buffering est limitée par la directive ProxyOfflineBuffer (par défaut 24 heures de données). Au-delà, les valeurs les plus anciennes sont écartées. Pour un proxy qui peut potentiellement rester déconnecté plus longtemps, on augmente cette valeur.
Étape 8 — Sécuriser la liaison proxy ↔ serveur
Par défaut, le trafic proxy ↔ serveur est en clair. Sur Internet ou inter-VLAN, on chiffre via PSK (clé partagée) ou TLS certificate. Le PSK est le plus simple à mettre en œuvre.
# Sur le proxy, générer une clé PSK
sudo openssl rand -hex 32 | sudo tee /etc/zabbix/proxy.psk
sudo chown zabbix:zabbix /etc/zabbix/proxy.psk
sudo chmod 600 /etc/zabbix/proxy.psk
# Configurer le proxy
sudo tee -a /etc/zabbix/zabbix_proxy.conf <<'EOF'
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=site-paris-proxy
TLSPSKFile=/etc/zabbix/proxy.psk
EOF
sudo systemctl restart zabbix-proxyCôté frontend, dans Administration → Proxies → site-paris-proxy → Encryption, on coche PSK pour les connexions IN et OUT, on saisit l’identité site-paris-proxy et le contenu du fichier PSK. À la prochaine reconnexion, le canal est chiffré.
Pour des environnements plus exigeants (banques, défense), on bascule sur des certificats X.509 émis par une PKI interne. La logique est la même mais avec TLSConnect=cert et les chemins vers les fichiers .crt et .key.
Étape 9 — Dimensionner le proxy
Un proxy moderne tient typiquement 1 000 à 5 000 hôtes selon les ressources de la machine. Sur un VM 2 vCPU + 4 Go RAM, on supervise confortablement 1 000 hôtes typiques. Au-delà, on monte les ressources ou on déploie un second proxy.
Les paramètres de tuning à connaître. StartPollers contrôle le nombre de threads de poll (défaut 5, augmenter à 20 pour des proxies chargés). CacheSize est la taille du cache de configuration (défaut 8M, monter à 64M pour 1000+ hôtes). HistoryCacheSize et HistoryIndexCacheSize contrôlent le cache de valeurs en attente d’envoi.
Étape 10 — Mettre en place la haute disponibilité de proxies (Zabbix 7)
Zabbix 7 introduit la haute disponibilité native pour les proxies via le concept de proxy group. On déclare un groupe contenant plusieurs proxies ; les hôtes assignés au groupe sont automatiquement répartis et redistribués si un proxy tombe.
Configuration côté serveur : Administration → Proxy groups → Create proxy group. On nomme le groupe (paris-cluster), on définit le Failover delay (60 secondes typiquement), on ajoute les proxies à inclure. Les hôtes assignés à ce groupe au lieu d’un proxy individuel sont alors gérés en HA.
Le mécanisme repose sur le fait que chaque proxy se déclare périodiquement actif auprès du serveur ; si un proxy ne signale plus sa présence pendant le failover delay, ses hôtes sont rebalancés vers les autres proxies du groupe automatiquement, sans intervention humaine.
Étape 11 — Surveiller le proxy lui-même
Un proxy qui tombe sans qu’on le sache est une supervision aveugle. On supervise donc le proxy lui-même comme n’importe quel autre hôte, idéalement directement par le serveur central (pas via le proxy lui-même, sinon en cas de panne on n’a aucune remontée).
Le template officiel Zabbix proxy health fournit les items et triggers pour surveiller la queue, le cache, les processes internes du proxy. À lier à l’hôte représentant le proxy ; trigger « proxy unreachable for 5 min » qui notifie l’astreinte d’infrastructure.
Étape 12 — Mettre à jour un proxy
Le proxy doit toujours rester à la même version mineure que le serveur. La compatibilité descendante (proxy plus ancien que serveur) est garantie sur quelques versions, mais pas l’inverse. Pour mettre à jour : sudo apt update && sudo apt upgrade zabbix-proxy-sqlite3 puis sudo systemctl restart zabbix-proxy.
La mise à jour applique les éventuelles migrations de schéma SQLite automatiquement. Si le démarrage échoue après upgrade, les logs indiquent généralement un problème de migration ; en dernier recours, supprimer la base SQLite (/var/lib/zabbix/zabbix_proxy.db) force la recréation, au prix d’une perte du backlog éventuel.
Étape 13 — Encrypter aussi le canal agent ↔ proxy
On a vu comment chiffrer la liaison proxy → serveur central. Le maillon agent → proxy mérite la même attention quand les agents sont sur Internet ou sur un réseau d’entreprise tiers. La configuration agent reprend les mêmes directives TLSConnect, TLSAccept, TLSPSKIdentity, TLSPSKFile, mais avec une clé PSK propre à la paire agent ↔ proxy.
Côté frontend, dans Configuration → Hosts → host → Encryption, on coche PSK pour les connexions et on saisit l’identité et la PSK de l’agent. À la prochaine reconnexion, le canal entre cet agent et le proxy est chiffré. Avec une politique TLS bout-en-bout (agent → proxy → serveur), aucun trafic Zabbix ne circule en clair, ce qui satisfait la majorité des contraintes de conformité (PCI DSS, ISO 27001, RGPD).
Étape 14 — Surveiller la queue du proxy
Une métrique critique d’un proxy est la taille de sa queue locale (nombre de valeurs en attente d’envoi). Tant qu’elle reste sous 100, tout va bien. Au-delà de 1000, le proxy peine à pousser. Au-delà de 10000, il y a soit une saturation de la liaison vers le serveur, soit un manque de threads d’envoi.
Le template Zabbix proxy health inclut un item qui interroge la queue ; on configure un trigger « queue > 5000 pendant 5 min ». La résolution typique est d’augmenter StartDataSenderProcesses dans la config proxy (défaut 1, monter à 3-5), qui multiplie le nombre de connexions parallèles vers le serveur central.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Proxy reste en statut « unknown » | Le proxy ne joint pas le serveur sur 10051 ou le Hostname diffère | Vérifier connectivité TCP avec nc -zv 10.0.0.10 10051 et alignement Hostname |
| Hôte déplacé n’envoie plus de données en mode active | ServerActive côté agent pointe encore vers le serveur central |
Modifier ServerActive pour pointer vers l’IP du proxy et redémarrer l’agent |
| Queue du proxy qui grossit en continu | Pas assez de pollers ou liaison vers serveur saturée | Augmenter StartPollers et DataSenderFrequency dans la config proxy |
| Erreur PSK « identity does not match » | Identité PSK mal copiée entre proxy et frontend | Vérifier exact match (casse comprise) entre TLSPSKIdentity et frontend |
| Base SQLite proxy corrompue après crash | Disque plein ou kill -9 pendant écriture | Supprimer /var/lib/zabbix/zabbix_proxy.db, le service la recrée |
Étape 15 — Architecture multi-tier de proxies
Pour les très gros déploiements (10 000+ hôtes répartis sur 50+ sites), un seul proxy par site n’est plus suffisant. On bascule en architecture multi-tier : des proxies de niveau 1 directement connectés au serveur central, et des proxies de niveau 2 qui agrègent plusieurs sous-sites avant de remonter. Cette hiérarchie réduit la charge réseau sur le serveur central et permet de scaler horizontalement.
Concrètement, le site régional Afrique de l’Ouest peut avoir un proxy par pays (Sénégal, Côte d’Ivoire, Mali) qui pousse vers un proxy régional consolidé, lequel pousse vers le serveur central en Europe. Cette topologie tolère mieux les coupures inter-régions et limite l’exposition réseau du serveur central. Le revers : la latence d’arrivée des métriques au serveur central augmente d’un saut, et le diagnostic d’incident devient plus complexe.