Table of Contents

1 Serveur

1 Serveur

Aperçu

Le serveur Zabbix est le processus central du logiciel Zabbix.

Le serveur effectue l'interrogation et la récupération des données, il calcule les déclencheurs, envoie des notifications aux utilisateurs. C'est le composant central auquel les agents et les proxys Zabbix rapportent des données de disponibilité et d'intégrité des systèmes. Le serveur peut lui-même vérifier à distance les services réseaux (tels que les serveurs Web et les serveurs de messagerie) à l'aide de simples vérifications de service.

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

Le fonctionnement d'un serveur Zabbix de base est divisé en trois composants distincts ; ce sont : le serveur Zabbix, l'interface Web et le stockage en base de données. Toutes les informations de configuration de Zabbix sont stockées dans la base de données, avec laquelle le serveur et l'interface Web interagissent. 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 de la base de données. Ensuite, environ une fois par minute, le serveur Zabbix interroge la table des éléments pour obtenir une liste des éléments actifs qui sont ensuite stockés dans un cache sur le serveur Zabbix. C'est pourquoi cela peut prendre jusqu'à deux minutes pour que toute modification apportée à l'interface Zabbix apparaisse dans la dernière section de données.

Serveur en cours d'exécution

Si installé en tant que package

Le serveur Zabbix fonctionne comme un processus démon. Le serveur peut être démarré en exécutant :

shell> service zabbix-server start

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

shell> /etc/init.d/zabbix-server start

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

shell> service zabbix-server stop
       shell> service zabbix-server restart
       shell> service zabbix-server status

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 :

shell> 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
       -h --help                       donner 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 :

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

Contrôle d'exécution

Options de contrôle d'exécution :

Option	Description	Cible
config_cache_reload	Recharge le cache de configuration. Ignoré si le cache est en cours de chargement.
diaginfo[=<target>]	Rassemble les informations de diagnostic dans le fichier journal du serveur.	historycache - statistiques du cache de l'historique valuecache - statistiques du cache de valeurs preprocessing - statistiques du gestionnaire de prétraitement alerting - statistiques du gestionnaire d'alertes lld - statistiques du manager LLD locks - liste des mutex (vide sur les systèmes *BSD)
ha_status	Journalise l'état du cluster haute disponibilité (HA).
ha_remove_node=target	Supprime le nœud 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éfinis le délai de basculement de la haute disponibilité (HA). Les suffixes temporels sont pris en charge, par exemple 10s, 1m.
secrets_reload	Recharge les secrets du Coffre.
service_cache_reload	Recharge le cache du gestionnaire de services.
snmp_cache_reload	Recharge le cache SNMP, efface les propriétés SNMP (heure du moteur, démarrages du moteur, ID du moteur, informations d'identification) pour tous les hôtes.
housekeeper_execute	Démarre la procédure de nettoyage. Ignoré si la procédure de nettoyage est en cours.
trigger_housekeeper_execute	Démarre la procédure de nettoyage des déclencheurs. Ignoré si la procédure de nettoyage des déclencheurs est en cours.
log_level_increase[=<target>]	Augmente le niveau de journalisation, affecte tous les processus si la cible n'est pas 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 serveur. process type,N - Type et nombre de processus (par exemple, poller,3) pid - Identificateur de processus (1 à 65535). Pour des valeurs supérieures, spécifiez la cible comme 'process type,N'.
log_level_decrease[=<target>]	Diminue le niveau de journalisation, affecte tous les processus si la cible n'est pas spécifiée. Non pris en charge sur les systèmes *BSD.
prof_enable[=<target>]	Active le profilage. Affecte tous les processus si la cible n'est pas spécifiée. Le profilage activé fournit des détails sur tous les rwlocks/mutexes par nom de fonction. Pris en charge depuis Zabbix 6.0.13.	process type - Tous les processus du type spécifié (par ex. history syncer) Types de processus pris en charge en tant que cibles de profilage : alerter, alert manager, availability manager, configuration syncer, discoverer, 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 et nombre de processus (par exemple, history syncer,1) pid - Identifiant du processus (1 à 65535). Pour des valeurs supérieures, spécifiez la cible comme 'process type,N'. scope - `rwlock`, `mutex`, `processing` peuvent être utilisés avec le type et le numéro de processus (par ex., history syncer,1,processing) ou à tous les processus de type (par ex., history syncer,rwlock)
prof_disable[=<target>]	Désactive le profilage. Affecte tous les processus si la cible n'est pas spécifiée. Pris en charge depuis Zabbix 6.0.13.	process type - Tous les processus du type spécifié (par exemple, le synchroniseur d'historique) Types de processus pris en charge en tant que cibles de profilage : voir `prof_enable` process type,N - Type et nombre de processus (par exemple, history syncer,1) pid - Identifiant du processus (1 à 65535). Pour des valeurs supérieures, 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 :

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

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

Gather all available diagnostic information in the server log file:
       shell> zabbix_server -R diaginfo
       
       Gather history cache statistics in the server log file:
       shell> zabbix_server -R diaginfo=historycache

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

shell> zabbix_server -R snmp_cache_reload

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

shell> 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 journal :

Increase log level of all processes:
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase
       
       Increase log level of second poller process:
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2
       
       Increase log level of process with PID 1234:
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234
       
       Decrease log level of all http poller processes:
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Exemple de réglage du délai de basculement HA sur un minimum de 10 secondes :

shell> zabbix_server -R ha_set_failover_delay=10s

Processus utilisateur

Le serveur Zabbix est conçu pour fonctionner en tant qu'utilisateur non root. Il fonctionnera avec n’importe quel utilisateur non-root qui lancera les processus. Vous pouvez donc exécuter le serveur en tant qu'utilisateur non root sans aucun problème.

Si vous essayez de l'exécuter en tant que 'root', il passera à un utilisateur 'zabbix' codé en dur, qui doit être présent sur votre système. Vous pouvez uniquement exécuter le serveur en tant que 'root' si vous modifiez le paramètre 'AllowRoot' dans le fichier de configuration associé du serveur.

Si le serveur et l'agent Zabbix sont exécutés sur la même machine, il est recommandé d'utiliser un autre utilisateur pour exécuter le serveur que pour exécuter l'agent. Sinon, si les deux sont exécutés 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 facilement récupérer, par exemple, le mot de passe de la base de données.

Fichier de configuration

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

Scripts de démarrage

Des scripts sont utilisés pour démarrer/arrêter automatiquement les processus Zabbix pendant le démarrage/l'arrêt du système. Les scripts sont situés dans le répertoire misc/init.d.

Types de processus serveur

alert manager - gestionnaire de file d'attente d'alertes
alert syncer - processus d'écriture des alertes en base de données
alerter - processus d'envoi des notifications
availability manager - processus de mise à jour de la disponibilité des hôtes
configuration syncer - processus de gestion du cache en mémoire des données de configuration
discoverer - processus de découverte des équipements
escalator - processus d'escalade des actions
history poller - processus de traitements calculés et vérifications internes nécessitant une connexion à la base de données
history syncer - processus d'écriture de l'historique en base de données
housekeeper - processus de suppression des anciennes données d'historique
http poller - poller pour la supervision web
icmp pinger - poller pour les vérifications icmpping
ipmi manager - gestionnaires de poller IPMI
ipmi poller - poller pour les vérifications IPMI
java poller - poller pour les vérifications Java
lld manager - processus de gestion des tâches de découverte de bas niveau
lld worker - processus de traitement 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
preprocessing worker - processus de pré-traitement des données
problem housekeeper - processus de suppression des problèmes liés à des déclencheurs supprimés
proxy poller - poller des proxys passifs
report manager- gestionnaire des tâches de génération de rapports planifiées
report writer - processus de génération de rapports planifiés
self-monitoring - processus de collecte des statistiques internes du serveur
snmp trapper - trapper pour les traps SNMP
task manager - processus pour l'exécution à distance de tâches demandées par d'autres composants (ex : fermeture d'un problème, acquittement d'un problème, vérification immédiate de la valeur d'un élément , fonctionnalité d'exécution de commande à distance)
timer - timer pour le traitement des maintenances
trapper - trapper pour les vérifications actives, les traps, la communication avec le proxy
unreachable poller - poller des équipements injoignables
vmware collector - collecte des données VMware responsable de la récupération des données pour les services VMware

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

Plusieurs types de processus du serveur Zabbix peuvent être supervisés en utilisant l'élément interne zabbix[process,<type>,<mode>,<state>] .

Plates-formes supportées

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

Le serveur Zabbix a été testé sur les plateformes suivantes :

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

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

Environnement local

Notez que le serveur requiert un environnement local UTF-8 afin que les éléments textuels puissent être interprétés correctement. La plupart des systèmes modernes de type Unix ont un paramètre régional UTF-8 par défaut, cependant, certains systèmes peuvent avoir besoin d'être définis spécifiquement.

Documentation