Le proxy Zabbix est un processus qui peut collecter les données de supervision d’un ou plusieurs dispositifs supervisés et envoyer ces informations au serveur Zabbix, agissant essentiellement au nom du serveur. Toutes les données collectées sont mises en mémoire tampon localement, puis transférées au serveur Zabbix auquel le proxy appartient.

Le déploiement d’un proxy est facultatif, mais peut être très utile pour répartir la charge d’un seul serveur Zabbix. Si seuls les proxies collectent les données, le traitement sur le serveur nécessite moins de ressources CPU et d’entrées/sorties disque.

Un proxy Zabbix est la solution idéale pour la supervision centralisée de sites distants, de succursales et de réseaux ne disposant pas d’administrateurs locaux.

Un proxy Zabbix nécessite une base de données distincte.

Notez que les bases de données prises en charge par le proxy Zabbix sont SQLite, MySQL et PostgreSQL.

Voir également :

Exécution du proxy

Si installé en tant que paquet

Zabbix proxy s’exécute comme un processus démon. Le proxy peut être démarré en exécutant :

systemctl start zabbix-proxy

Cela fonctionnera sur la plupart des systèmes GNU/Linux. Sur d’autres systèmes, vous devrez peut-être exécuter :

/etc/init.d/zabbix-proxy start

De même, pour arrêter/redémarrer/afficher l’état de Zabbix proxy, utilisez les commandes suivantes :

systemctl stop zabbix-proxy
systemctl restart zabbix-proxy
systemctl status zabbix-proxy

Démarrer manuellement

Si ce qui précède ne fonctionne pas, vous devez le démarrer manuellement. Trouvez le chemin vers le binaire zabbix_proxy et exécutez :

zabbix_proxy

Vous pouvez utiliser les paramètres de ligne de commande suivants avec le proxy Zabbix :

Parameter	Description
`-c --config <config-file>`	Chemin vers le fichier de configuration.
`-f --foreground`	Exécuter le proxy Zabbix au premier plan.
`-R --runtime-control <option>`	Effectuer des fonctions administratives.
`-T --test-config`	Valider le fichier de configuration et quitter.
`-h --help`	Afficher les informations d'aide et quitter.
`-V --version`	Afficher le numéro de version.

Exemples d'exécution du proxy Zabbix avec des paramètres de ligne de commande :

zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf
zabbix_proxy --help
zabbix_proxy -V

Contrôle à chaud

Options de contrôle à chaud :

Option	Description	Cible
`config_cache_reload`	Recharge le cache de configuration. Ignoré si le cache est en cours de chargement. Le proxy Zabbix actif se connectera au serveur Zabbix et demandera les données de configuration. Le proxy Zabbix passif demandera les données de configuration au serveur Zabbix lors de la prochaine connexion du serveur au proxy.
`history_cache_clear=target`	Vide le cache d'historique pour l'élément spécifié par son ID. Affecte toutes les valeurs de l'élément, à l'exception de la première et de la dernière valeur.	target - ID de l'élément.
`diaginfo[=<section>]`	Collecte des informations de diagnostic dans le fichier journal du proxy.	`historycache` - statistiques du cache d'historique; `preprocessing` - statistiques du gestionnaire de prétraitement; `locks` - liste des mutex (vide sur les systèmes BSD).
`snmp_cache_reload`	Recharge le cache SNMP - efface les propriétés du moteur SNMP (engine time, engine boots, engine id, credentials) pour tous les hôtes. À utiliser pour forcer un effacement global du cache lors du dépannage des problèmes SNMP.
`housekeeper_execute`	Démarre la procédure de housekeeping. Ignoré si la procédure de housekeeping est actuellement en cours.
`log_level_increase[=<target>]`	Augmente le niveau de journalisation, affecte tous les processus si aucune cible n'est spécifiée. Non pris en charge sur les systèmes BSD.	process type - tous les processus du type spécifié (par exemple, `poller`). Voir tous les types de processus du proxy. process type,N - type de processus et numéro (par exemple, `poller,3`) pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus élevées, spécifiez la cible sous la forme 'process type,N'.
`log_level_decrease[=<target>]`	Diminue le niveau de journalisation, affecte tous les processus si aucune cible n'est spécifiée. Non pris en charge sur les systèmes BSD.
`prof_enable[=<target>]`	Active le profilage. Affecte tous les processus si aucune cible n'est spécifiée. Le profilage activé fournit des détails sur tous les rwlocks/mutexes par nom de fonction.	process type - tous les processus du type spécifié (par exemple, `history syncer`). Voir tous les types de processus du proxy. process type,N - type de processus et numéro (par exemple, `history syncer,1`). pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus élevées, spécifiez la cible sous la forme 'process type,N'. scope - `rwlock`, `mutex`, `processing` peuvent être utilisés avec le type de processus et le numéro (par exemple, `history syncer,1,processing`) ou avec tous les processus d'un type (par exemple, `history syncer,rwlock`).
`prof_disable[=<target>]`	Désactive le profilage. Affecte tous les processus si aucune cible n'est spécifiée.	process type - tous les processus du type spécifié (par exemple, `history syncer`). Voir tous les types de processus du proxy. process type,N - type de processus et numéro (par exemple, `history syncer,1`). pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus élevées, spécifiez la cible sous la forme 'process type,N'.

Lorsqu'un type de processus est spécifié comme cible pour le contrôle à chaud, la commande s'applique uniquement aux processus en cours d'exécution de ce type. Si aucun processus du type spécifié n'est en cours d'exécution, la commande renvoie une erreur :

zabbix_proxy -R log_level_increase='data sender'
Cannot redirect signal: "data sender" process does not exist

Exemple d'utilisation du contrôle à chaud pour recharger le cache de configuration du proxy :

zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R config_cache_reload

Exemple d'utilisation du contrôle à chaud pour vider le cache d'historique d'un élément :

zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R history_cache_clear=42243

Exemples d'utilisation du contrôle à chaud pour collecter des informations de diagnostic :

# Collecter toutes les informations de diagnostic disponibles dans le fichier journal du proxy :
zabbix_proxy -R diaginfo

# Collecter les statistiques du cache d'historique dans le fichier journal du proxy :
zabbix_proxy -R diaginfo=historycache

Exemple d'utilisation du contrôle à chaud pour recharger le cache SNMP :

zabbix_proxy -R snmp_cache_reload

Lorsqu'une interface SNMPv3 est mise à jour via l'interface Zabbix, Zabbix recharge automatiquement les nouveaux identifiants SNMPv3 pour cette interface dans la plupart des cas ; utilisez -R snmp_cache_reload uniquement si la collecte échoue encore après un changement d'identifiants (par exemple, en raison d'incohérences engineBoots/engineID ou de périphériques non conformes RFC), ou lorsque vous devez forcer un effacement global du cache SNMP pour le dépannage.

Exemple d'utilisation du contrôle à chaud pour déclencher l'exécution du housekeeper :

zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R housekeeper_execute

Exemples d'utilisation du contrôle à chaud pour modifier le niveau de journalisation :

# Augmenter le niveau de journalisation de tous les processus :
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase

# Augmenter le niveau de journalisation du deuxième processus poller :
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,2

# Augmenter le niveau de journalisation du processus avec le PID 1234 :
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=1234

# Diminuer le niveau de journalisation de tous les processus http poller :
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="http poller"

Exécuter le proxy en tant qu’utilisateur

Le proxy Zabbix est conçu pour s’exécuter en tant qu’utilisateur non root. Il s’exécutera avec l’utilisateur non root sous lequel il a été démarré. Vous pouvez donc exécuter le proxy avec n’importe quel utilisateur non root sans problème.

Si vous essayez de l’exécuter en tant que « root », il basculera vers un utilisateur « zabbix » codé en dur, qui doit être présent sur votre système. Vous ne pouvez exécuter le proxy en tant que « root » que si vous modifiez en conséquence le paramètre AllowRoot dans le fichier de configuration du proxy.

Fichier de configuration

Le chemin par défaut du fichier de configuration dépend du système d'exploitation et de la méthode d'installation de Zabbix :

Pour une installation à partir des sources : /usr/local/etc/zabbix_proxy.conf, ou tel que défini par les variables de compilation --sysconfdir ou --prefix.
Pour une installation à partir de paquets : /etc/zabbix/zabbix_proxy.conf.

Consultez les options du fichier de configuration pour plus de détails sur la configuration de zabbix_proxy.

Types de processus et threads du proxy

agent poller - processus de sondage asynchrone pour les vérifications passives avec un thread de travail ;
apm manager - processus gestionnaire pour la surveillance des performances des applications (APM) ;
apm worker - processus chargé de traiter les tâches de surveillance des performances des applications (APM) provenant de apm manager ;
availability manager - processus chargé de mettre à jour la disponibilité des hôtes ;
browser poller - processus de sondage pour les vérifications des éléments de type navigateur ;
configuration syncer - processus chargé de gérer le cache en mémoire des données de configuration ;
data sender - processus d'envoi des données du proxy ;
discovery manager - processus gestionnaire chargé de la découverte des périphériques ;
discovery worker - processus chargé de traiter les tâches de découverte provenant de discovery manager ;
history syncer - processus d'écriture dans la base de données d'historique ;
housekeeper - processus chargé de supprimer l'historique obsolète des éléments ;
http agent poller - processus de sondage asynchrone pour les vérifications HTTP avec un thread de travail ;
http poller - processus de sondage de la surveillance web ;
icmp pinger - processus de sondage pour les vérifications icmpping ;
internal poller - processus de sondage pour les vérifications internes ;
ipmi manager - gestionnaire des processus de sondage IPMI ;
ipmi poller - processus de sondage pour les vérifications IPMI ;
java poller - processus de sondage pour les vérifications Java ;
odbc poller - processus de sondage pour les vérifications ODBC ;
poller - processus de sondage normal pour les vérifications passives ;
preprocessing manager - gestionnaire des tâches de prétraitement avec des threads de travail de prétraitement ;
preprocessing worker - thread chargé du prétraitement des données ;
self-monitoring - processus chargé de collecter les statistiques internes du serveur ;
snmp poller - processus de sondage asynchrone pour les vérifications SNMP avec un thread de travail (uniquement les éléments walk[OID] et get[OID]) ;
snmp trapper - processus trapper pour les traps SNMP ;
supervisor - coordonne le démarrage et l'arrêt des processus et threads du serveur, et surveille leur état de préparation ;
task manager - processus chargé de l'exécution à distance des tâches demandées par d'autres composants (par exemple, fermer un problème, confirmer un problème, vérifier immédiatement la valeur d'un élément, fonctionnalité de commande à distance) ;
telemetry query poller - processus de sondage pour les vérifications des éléments de type requête de télémétrie ;
trapper - processus trapper pour les vérifications actives, les traps et la communication avec le proxy ;
unreachable poller - processus de sondage pour les périphériques inaccessibles ;
vmware collector - collecteur de données VMware chargé de recueillir les données des services VMware.

Le fichier journal du proxy peut être utilisé pour observer ces types de processus.

Le fichier journal du proxy est créé avec des autorisations de lecture-écriture uniquement pour son propriétaire. De plus, le fichier est lisible par le groupe propriétaire. Toutes les autres autorisations sont refusées.

Différents types de processus du proxy Zabbix peuvent être surveillés à l'aide de l'élément interne zabbix[process,<type>,<mode>,<state>].

Statistiques des transactions du synchroniseur d'historique

Le titre du processus du synchroniseur d'historique affiche des statistiques détaillées sur les transactions du synchroniseur d'historique.

205276 ?        S      0:00  zabbix_proxy: history syncer #1 [processed 1 values in 0.001179 (0.001167,0.000000) sec, idle 1 sec]
205277 ?        S      0:00  zabbix_proxy: history syncer #2 [processed 0 values in 0.000022 (0.000000,0.000000) sec, idle 1 sec]

Les durées, dans processed...in N (<timings>) sec, sont :

Temps passé à écrire les valeurs des éléments dans la base de données.
Temps passé à mettre à jour les données de l'élément (état, erreurs).

Procédure de housekeeping

Le proxy Zabbix dispose du processus housekeeper qui supprime l'historique et les tendances obsolètes des éléments. Il s'exécute par cycles, avec une fréquence déterminée par HousekeepingFrequency, et la limite de suppression par cycle déterminée par ProxyLocalBuffer et ProxyOfflineBuffer. Contrairement à la procédure de housekeeping du serveur Zabbix, le processus housekeeper du proxy n'utilise pas la table housekeeper — il supprime toutes les données obsolètes une fois par cycle de housekeeping.

Plates-formes prises en charge

Le proxy Zabbix fonctionne sur la même liste de plates-formes prises en charge que le serveur Zabbix.

Tampon mémoire

Le tampon mémoire permet de stocker de nouvelles données (valeurs d'élément, découverte réseau, auto-enregistrement de hôte) dans le tampon et de les envoyer au serveur Zabbix sans accéder à la base de données. Le tampon mémoire a été introduit pour le proxy dans Zabbix 7.0.

Dans les installations antérieures à Zabbix 7.0, les données collectées étaient stockées dans la base de données avant d'être envoyées au serveur Zabbix. Pour ces installations, cela reste le comportement par défaut après la mise à niveau vers Zabbix 7.0.

Pour des performances optimisées, il est recommandé de configurer l'utilisation du tampon mémoire sur le proxy. Cela est possible en modifiant la valeur de ProxyBufferMode de disk (valeur par défaut codée en dur pour les installations existantes) à hybrid (recommandé) ou memory. Il est également nécessaire de définir la taille du tampon mémoire (paramètre ProxyMemoryBufferSize).

En mode hybride, le tampon est protégé contre la perte de données en vidant vers la base de données les données non envoyées si le proxy est arrêté, si le tampon est plein ou si les données sont trop anciennes. Lorsque toutes les valeurs ont été vidées dans la base de données, le proxy recommence à utiliser le tampon mémoire.

En mode mémoire, le tampon mémoire sera utilisé, mais il n'y a aucune protection contre la perte de données. Si le proxy est arrêté ou si la mémoire est saturée, les données non envoyées seront supprimées.

Le mode hybride (ProxyBufferMode=hybrid) est appliqué à toutes les nouvelles installations depuis Zabbix 7.0.

Des paramètres supplémentaires tels que ProxyMemoryBufferSize et ProxyMemoryBufferAge définissent respectivement la taille du tampon mémoire et l'âge maximal des données dans le tampon.

Notez qu'en cas de configuration conflictuelle, le proxy affichera une erreur et ne parviendra pas à démarrer, par exemple si :

ProxyBufferMode est défini sur hybrid ou memory et ProxyMemoryBufferSize vaut 0.
ProxyBufferMode est défini sur hybrid ou memory et ProxyLocalBuffer n'est pas 0.

Locale

Notez que le proxy nécessite une locale UTF-8 afin que certains éléments textuels puissent être interprétés correctement. La plupart des systèmes Unix modernes ont une locale UTF-8 par défaut, cependant, sur certains systèmes, il peut être nécessaire de la définir explicitement.

Calcul des files d'attente pendant la maintenance

Le proxy Zabbix n'est pas informé des périodes de maintenance ; voir Calcul des files d'attente pendant la maintenance pour plus de détails.

Utilisation de l'interface Zabbix derrière un proxy

Si l'interface Zabbix s'exécute derrière un serveur proxy, le chemin du cookie dans le fichier de configuration du proxy doit être réécrit afin de correspondre au chemin utilisé par le proxy inverse. Voir les exemples ci-dessous. Si le chemin du cookie n'est pas réécrit, les utilisateurs peuvent rencontrer des problèmes d'autorisation lorsqu'ils tentent de se connecter à l'interface Zabbix.

Exemple de configuration pour NGINX

# ..
location / {
# ..
proxy_cookie_path /zabbix /;
proxy_pass http://192.168.0.94/zabbix/;
# ..

Exemple de configuration pour Apache

# ..
ProxyPass "/" http://host/zabbix/
ProxyPassReverse "/" http://host/zabbix/
ProxyPassReverseCookiePath /zabbix /
ProxyPassReverseCookieDomain host zabbix.example.com
# ..

Quelle est la prochaine étape ?

Surveillance distribuée à l'aide de proxies

Docs

proxy

Vue d’ensemble