Le serveur effectue le sondage et la réception des données, il calcule les déclencheurs, envoie des notifications aux utilisateurs. C'est le composant central auquel les agents Zabbix et les proxies transmettent des données sur la disponibilité et l'intégrité des systèmes. Le serveur peut lui-même vérifier à distance des services en réseau (tels que des serveurs web et des serveurs de messagerie) à l'aide de simples contrôles de service.

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 se divise en trois composants distincts ; ce sont : le serveur Zabbix, l'interface web et le stockage de la 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 des éléments dans la base de données. Ensuite, environ une fois par minute, le serveur Zabbix interrogera la table des éléments pour obtenir une 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 toute modification effectuée dans l'interface Zabbix n'apparaisse 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émarrer manuellement

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 (par défaut : /usr/local/etc/zabbix_server.conf)
-f --foreground                 Exécuter le serveur Zabbix au premier plan
-R --runtime-control <option>   Effectuer des fonctions d'administration
-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 valeur.	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 ayant la plus grande file d'attente.
`ha_status`	Journaliser 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 actif/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 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, la configuration de tous les proxy est rechargée.
`secrets_reload`	Recharger les secrets depuis Vault.
`service_cache_reload`	Recharger le cache du gestionnaire de services.
`snmp_cache_reload`	Recharger le cache SNMP — efface les propriétés du moteur SNMP (temps du moteur, démarrages du moteur, ID du moteur, identifiants) pour tous les hôtes. À utiliser pour forcer un effacement global du cache lors du dépannage des problèmes SNMP.
`housekeeper_execute`	Démarrer la procédure de housekeeping. Ignoré si la procédure de housekeeping est déjà en cours.
`trigger_housekeeper_execute`	Démarrer la procédure de housekeeping des déclencheurs. Ignoré si la procédure de housekeeping des déclencheurs est déjà en cours. Jusqu'au démarrage de la procédure de housekeeping des déclencheurs, les problèmes causés par des déclencheurs qui ont depuis été supprimés peuvent encore générer des problèmes de service et leur être attribués. Si votre configuration implique de nombreuses règles de calcul d'état de service basées sur des déclencheurs fréquemment découverts/non découverts, envisagez d'augmenter la fréquence de la procédure de housekeeping en ajustant le paramètre de configuration du serveur `ProblemHousekeepingFrequency`.
`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.	type de processus - tous les processus du type spécifié (par exemple, `poller`). Voir tous les types de processus du serveur. type de processus,N - type de processus et numéro (par exemple, `poller,3`). pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez la cible comme 'type de processus,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/mutex par nom de fonction.	type de processus - tous les processus du type spécifié (par exemple, `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`. type de processus,N - type de processus et numéro (par exemple, `history syncer,1`). pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez la cible comme 'type de processus,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 du type (par exemple, `history syncer,rwlock`).
`prof_disable[=<target>]`	Désactiver le profilage. Affecte tous les processus si aucune cible n'est spécifiée.	type de processus - tous les processus du type spécifié (par exemple, `history syncer`). Types de processus pris en charge comme cibles de profilage : voir `prof_enable`. type de processus,N - type de processus et numéro (par exemple, `history syncer,1`). pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez la cible comme 'type de processus,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 sous un utilisateur non-root. Il s'exécutera sous l'utilisateur non-root avec lequel il a été 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 un 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 s'exécutent sur la même machine, il est recommandé d'utiliser un utilisateur différent pour exécuter le serveur et l'agent. Sinon, si les deux s'exécutent sous 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 poller asynchrone pour les vérifications passives avec un thread de travail ;
alert manager - gestionnaire de la file d'attente des alertes ;
alert syncer - écrivain de la base de données des alertes ;
alerter - processus d'envoi des notifications ;
availability manager - processus de mise à jour de la disponibilité des hôtes ;
browser poller - poller 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 provenant du gestionnaire de connecteurs ;
discovery manager - processus gestionnaire de la découverte des périphériques ;
discovery worker - processus de traitement des tâches de découverte provenant du gestionnaire de découverte ;
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 - écrivain de la base de données d'historique ;
housekeeper - processus de suppression des données obsolètes (historique et tendances des éléments, sessions utilisateur, événements, etc.), ainsi que des données laissées par des objets supprimés ;
http agent poller - processus de poller asynchrone pour les vérifications HTTP avec un thread de travail ;
http poller - poller de supervision web ;
icmp pinger - poller pour les vérifications icmpping ;
internal poller - poller pour les vérifications internes ;
ipmi manager - gestionnaire de poller IPMI ;
ipmi poller - poller pour les vérifications IPMI ;
java poller - poller 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 - poller pour les vérifications ODBC ;
poller - poller 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 - poller 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 planifiée des rapports ;
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 balises de problème et la récupération des problèmes depuis history syncer, task manager et alert manager ;
snmp poller - processus de poller asynchrone pour les vérifications SNMP avec un thread de travail (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 exemple, fermer un problème, acquitter un problème, vérifier la valeur d'un élément maintenant, fonctionnalité de commande à distance) ;
timer - minuteur 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 et des événements générés par des déclencheurs qui ont depuis été supprimés ;
unreachable poller - poller 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.

Depuis Zabbix 7.4.6, le fichier journal du serveur est créé avec des permissions de lecture et d'écriture uniquement pour le propriétaire du fichier. En outre, 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 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 :

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 minuteries.

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 des éléments (état, erreurs, inventaire de l'hôte, etc.) ;
Temps passé à vider les tendances vers la base de données ;
Temps passé à calculer les déclencheurs ;
Temps passé à traiter les événements et les 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