This is a translation of the original English documentation page. Help us make it better.

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.