Le serveur effectue l’interrogation et la réception des données, calcule les déclencheurs et envoie des notifications aux utilisateurs. Il s’agit du composant central auquel les agents et les proxies Zabbix transmettent les données sur la disponibilité et l’intégrité des systèmes. Le serveur peut également vérifier à distance les services réseau (tels que les serveurs web et les serveurs de messagerie) à l’aide de contrôles de service simples.

Le serveur est le référentiel central dans lequel sont stockées toutes les données de configuration, statistiques et opérationnelles, et c’est l’entité de Zabbix qui alertera activement les administrateurs lorsque des problèmes surviennent sur l’un des systèmes surveillés.

Le fonctionnement d’un serveur Zabbix de base est divisé en trois composants distincts ; il s’agit de : serveur Zabbix, interface web et stockage de base de données.

Toutes les informations de configuration de Zabbix sont stockées dans la base de données, avec laquelle interagissent à la fois le serveur et l’interface web. Par exemple, lorsque vous créez un nouvel élément à l’aide de l’interface web (ou de l’API), il est ajouté à la table items de la base de données. Ensuite, environ une fois par minute, le serveur Zabbix interroge la table items pour obtenir la liste des éléments actifs, qui est ensuite stockée dans un cache au sein du serveur Zabbix. C’est pourquoi il peut s’écouler jusqu’à deux minutes avant que les modifications effectuées dans l’interface Zabbix n’apparaissent dans la section des dernières données.

Exécution du serveur

Si installé en tant que paquet

Le serveur Zabbix s’exécute en tant que processus démon. Le serveur peut être démarré en exécutant :

systemctl start zabbix-server

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-server start

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

systemctl stop zabbix-server
systemctl restart zabbix-server
systemctl status zabbix-server

Démarrage manuel

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

zabbix_server

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

-c --config <file>              chemin vers le fichier de configuration (la valeur par défaut est /usr/local/etc/zabbix_server.conf)
-f --foreground                 exécuter le serveur 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 cette aide
-V --version                    afficher le numéro de version

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

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

Contrôle d'exécution

Options de contrôle d'exécution :

Option	Description	Cible
config_cache_reload	Recharger le cache de configuration. Ignoré si le cache est en cours de chargement.
history_cache_clear=target	Vider le cache d'historique pour l'élément spécifié par son ID. Affecte toutes les valeurs de l'élément, sauf la première et la dernière.	target - ID de l'élément
diaginfo[=<section>]	Collecter des informations de diagnostic dans le fichier journal du serveur.	historycache - statistiques du cache d'historique valuecache - statistiques du cache de valeurs preprocessing - statistiques du gestionnaire de prétraitement alerting - statistiques du gestionnaire d'alertes lld - statistiques du gestionnaire LLD locks - liste des mutex (vide sur les systèmes BSD) connector - statistiques des connecteurs avec la plus grande file d'attente
ha_status	Consigner l'état du cluster de haute disponibilité (HA).
ha_remove_node=target	Supprimer le nœud de haute disponibilité (HA) spécifié par son nom ou son ID. Notez que les nœuds actifs/en veille ne peuvent pas être supprimés.	target - nom ou ID du nœud (peut être obtenu en exécutant ha_status)
ha_set_failover_delay=delay	Définir le délai de basculement de la haute disponibilité (HA). Les suffixes de temps sont pris en charge, par exemple 10s, 1m.
proxy_config_cache_reload[=<target>]	Recharger le cache de configuration du proxy.	target - liste de noms de proxy séparés par des virgules Si aucune cible n'est spécifiée, recharger la configuration de tous les proxys
secrets_reload	Recharger les secrets depuis Vault.
service_cache_reload	Recharger le cache du gestionnaire de services.
snmp_cache_reload	Recharger le cache SNMP — effacer 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 de problèmes SNMP.
housekeeper_execute	Démarrer la procédure de nettoyage. Ignoré si la procédure de nettoyage est actuellement en cours.
trigger_housekeeper_execute	Démarrer la procédure de nettoyage des déclencheurs pour les services afin de supprimer les problèmes causés par des déclencheurs qui ont depuis été supprimés, y compris les problèmes de service générés par ces problèmes (considérés comme résolus au moment du nettoyage). Notez que, tant que la procédure de nettoyage n'est pas lancée, les problèmes causés par des déclencheurs désormais supprimés peuvent encore générer des problèmes de service et les attribuer à des services. Si votre configuration implique de nombreuses règles de calcul d'état de service basées sur des déclencheurs fréquemment découverts/supprimés, envisagez d'augmenter la fréquence de la procédure de nettoyage des déclencheurs en ajustant le paramètre de configuration du serveur ProblemHousekeepingFrequency. Ignoré si la procédure de nettoyage des déclencheurs est actuellement en cours.
log_level_increase[=<target>]	Augmenter 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 ex., poller) Voir tous les types de processus du serveur. process type,N - Type de processus et numéro (par ex., poller,3) pid - Identifiant du processus (1 à 65535). Pour des valeurs plus grandes, spécifiez la cible comme 'process type,N'.
log_level_decrease[=<target>]	Diminuer 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>]	Activer 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 ex. history syncer) Types de processus pris en charge comme cibles de profilage : alerter, alert manager, availability manager, configuration syncer, discovery manager, escalator, history poller, history syncer, housekeeper, http poller, icmp pinger, ipmi manager, ipmi poller, java poller, lld manager, lld worker, odbc poller, poller, preprocessing manager, preprocessing worker, proxy poller, self-monitoring, service manager, snmp trapper, task manager, timer, trapper, unreachable poller, vmware collector process type,N - Type de processus et numéro (par ex., history syncer,1) pid - Identifiant du processus (1 à 65535). Pour des valeurs plus grandes, spécifiez la cible comme 'process type,N'. scope - `rwlock`, `mutex`, `processing` peuvent être utilisés avec le type et le numéro du processus (par ex., history syncer,1,processing) ou tous les processus du type (par ex., history syncer,rwlock)
prof_disable[=<target>]	Désactiver le profilage. Affecte tous les processus si aucune cible n'est spécifiée.	process type - Tous les processus du type spécifié (par ex. history syncer) Types de processus pris en charge comme cibles de profilage : voir `prof_enable` process type,N - Type de processus et numéro (par ex., history syncer,1) pid - Identifiant du processus (1 à 65535). Pour des valeurs plus grandes, spécifiez la cible comme 'process type,N'.

Exemple d'utilisation du contrôle d'exécution pour recharger le cache de configuration du serveur :

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

Exemples d'utilisation du contrôle d'exécution pour recharger la configuration du proxy :

# Recharger la configuration de tous les proxys :
zabbix_server -R proxy_config_cache_reload

# Recharger la configuration de Proxy1 et Proxy2 :
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

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

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

Exemples d'utilisation du contrôle d'exécution pour collecter des informations de diagnostic :

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

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

Exemple d'utilisation du contrôle d'exécution pour recharger le cache SNMP :

zabbix_server -R snmp_cache_reload

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

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

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

Exemples d'utilisation du contrôle d'exécution pour modifier le niveau de journalisation :

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

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

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

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

Exemple de définition du délai de basculement HA au minimum de 10 secondes :

zabbix_server -R ha_set_failover_delay=10s

Utilisateur du processus

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

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

Si le serveur Zabbix et l’agent sont exécutés sur la même machine, il est recommandé d’utiliser un utilisateur différent pour exécuter le serveur et pour exécuter l’agent. Sinon, si les deux sont exécutés avec le même utilisateur, l’agent peut accéder au fichier de configuration du serveur et tout utilisateur de niveau Admin dans Zabbix peut assez facilement récupérer, par exemple, le mot de passe de la base de données.

Fichier de configuration

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

Scripts de démarrage

Les scripts sont utilisés pour démarrer/arrêter automatiquement les processus Zabbix lors du démarrage/de l’arrêt du système. Les scripts se trouvent dans le répertoire misc/init.d.

Types de processus et threads du serveur

agent poller - processus de collecte asynchrone pour les vérifications passives avec un thread de travail
alert manager - gestionnaire de la file d’attente des alertes
alert syncer - processus d’écriture des alertes dans la base de données
alerter - processus d’envoi des notifications
availability manager - processus de mise à jour de la disponibilité des hôtes
browser poller - collecteur pour les vérifications des éléments de navigateur
configuration syncer - processus de gestion du cache en mémoire des données de configuration
configuration syncer worker - processus de résolution et de synchronisation des valeurs des macros utilisateur dans les noms d’éléments
connector manager - processus gestionnaire des connecteurs
connector worker - processus de traitement des requêtes du connector manager
discovery manager - processus gestionnaire de la découverte des périphériques
discovery worker - processus de traitement des tâches de découverte du discovery manager
escalator - processus d’escalade des actions
ha manager - processus de gestion de la haute disponibilité
history poller - processus de traitement des vérifications calculées nécessitant une connexion à la base de données
history syncer - processus d’écriture de l’historique dans la base de données
housekeeper - processus de suppression des anciennes données historiques
http agent poller - processus de collecte asynchrone pour les vérifications HTTP avec un thread de travail
http poller - collecteur de supervision web
icmp pinger - collecteur pour les vérifications icmpping
internal poller - collecteur pour les vérifications internes
ipmi manager - gestionnaire des collecteurs IPMI
ipmi poller - collecteur pour les vérifications IPMI
java poller - collecteur pour les vérifications Java
lld manager - processus gestionnaire des tâches de découverte de bas niveau
lld worker - processus de travail des tâches de découverte de bas niveau
odbc poller - collecteur pour les vérifications ODBC
poller - collecteur 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 de prétraitement des données
proxy poller - collecteur pour les proxies passifs
proxy group manager - gestionnaire de l’équilibrage de charge et de la haute disponibilité des proxies
report manager- gestionnaire des tâches de génération de rapports planifiés
report writer - processus de génération des rapports planifiés
self-monitoring - processus de collecte des statistiques internes du serveur
service manager - processus de gestion des services en recevant des informations sur les problèmes, les tags de problème et la récupération des problèmes depuis history syncer, task manager et alert manager
snmp poller - processus de collecte asynchrone pour les vérifications SNMP avec un thread de travail (éléments walk[OID] et get[OID] uniquement)
snmp trapper - trapper pour les traps SNMP
task manager - processus d’exécution à distance des tâches demandées par d’autres composants (par ex. fermer un problème, acquitter un problème, vérifier la valeur d’un élément maintenant, fonctionnalité de commande à distance)
timer - temporisateur pour le traitement des maintenances
trapper - trapper pour les vérifications actives, les traps, la communication avec les proxies
trigger housekeeper - processus de suppression des problèmes générés par des déclencheurs qui ont été supprimés
unreachable poller - collecteur pour les périphériques injoignables
vmware collector - collecteur de données VMware chargé de la collecte des données depuis les services VMware

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

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

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

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 :

205182 ?        S      0:00  zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
205183 ?        S      0:00  zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
205184 ?        S      0:00  zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]

Dans « A+B triggers » :

A - déclencheurs traités en raison des valeurs d’historique ;
B - déclencheurs traités en raison des temporisateurs.

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

Temps consacré à l’écriture des valeurs d’élément dans la base de données ;
Temps consacré à la mise à jour des données d’élément (état, erreurs, inventaire de l’hôte, etc.) ;
Temps consacré à l’écriture des tendances dans la base de données ;
Temps consacré au calcul des déclencheurs ;
Temps consacré au traitement des événements et des actions.

Plateformes prises en charge

En raison des exigences de sécurité et du caractère critique du fonctionnement du serveur, UNIX est le seul système d’exploitation capable de fournir de manière constante les performances, la tolérance aux pannes et la résilience nécessaires. Zabbix fonctionne sur les principales versions du marché.

Le serveur Zabbix est testé sur les plateformes suivantes :

Linux
Solaris
AIX
HP-UX
Mac OS X
FreeBSD
OpenBSD
NetBSD
SCO Open Server

Zabbix peut également fonctionner sur d’autres systèmes d’exploitation de type Unix.

Paramètres régionaux

Notez que le serveur nécessite des paramètres régionaux UTF-8 afin que certains éléments textuels puissent être interprétés correctement. La plupart des systèmes modernes de type Unix utilisent des paramètres régionaux UTF-8 par défaut ; toutefois, sur certains systèmes, il peut être nécessaire de les définir explicitement.

What’s next?

1 Haute disponibilité

Docs

1 Serveur

Aperçu