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 à l'exécution

Options de contrôle à l'exécution :

Option	Description	Target
`config_cache_reload`	Recharge le cache de configuration. Ignoré si le cache est en cours de chargement.
`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, sauf la première et la dernière valeur.	target - ID de l'élément
`diaginfo[=<section>]`	Collecte 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`	Journalise l'état du cluster de haute disponibilité (HA).
`ha_remove_node=target`	Supprime le nœud de haute disponibilité (HA) spécifié par son nom ou son ID. Notez que les nœuds actif/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éfinit 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>]`	Recharge le cache de configuration du proxy.	target - liste des noms de proxy séparés par des virgules. Si aucun target n'est spécifié, recharge la configuration de tous les proxy.
`secrets_reload`	Recharge les secrets depuis Vault.
`service_cache_reload`	Recharge le cache du gestionnaire de services.
`snmp_cache_reload`	Recharge 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émarre la procédure de housekeeping. Ignoré si la procédure de housekeeping est actuellement en cours.
`trigger_housekeeper_execute`	Démarre la procédure de housekeeping des déclencheurs. Ignoré si la procédure de housekeeping des déclencheurs est actuellement en cours.
`log_level_increase[=<target>]`	Augmente le niveau de journalisation, affecte tous les processus si target n'est pas spécifié. 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 serveur. process type,N - type de processus et numéro (par exemple, `poller,3`). pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez target comme 'process type,N'.
`log_level_decrease[=<target>]`	Diminue le niveau de journalisation, affecte tous les processus si target n'est pas spécifié. Non pris en charge sur les systèmes BSD.
`prof_enable[=<target>]`	Active le profilage. Affecte tous les processus si target n'est pas spécifié. Le profilage activé fournit des détails sur tous les rwlocks/mutex par nom de fonction.	process type - 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`. process type,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 target comme '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 target n'est pas spécifié.	process type - tous les processus du type spécifié (par exemple, `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 exemple, `history syncer,1`). pid - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez target 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 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 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 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 - 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 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 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 de 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 planifiée de 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 collecte asynchrone pour les vérifications SNMP avec un thread de travail (walk[OID] et get[OID] uniquement) ;
snmp trapper - récepteur des 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 - récepteur pour les vérifications actives, les traps et la communication avec le proxy ;
trigger housekeeper - processus de suppression des problèmes et événements générés par des déclencheurs qui ont depuis é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 provenant des 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 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>] élément.

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.

Procédure de housekeeping

Le processus housekeeper supprime périodiquement les données obsolètes (historique et tendances des éléments, sessions utilisateur, événements, etc.), ainsi que les données laissées par des objets supprimés. Il s'exécute par cycles, avec une fréquence et une limite de suppression par cycle déterminées par HousekeepingFrequency et MaxHousekeeperDelete. Toute donnée non supprimée lors d'un cycle est reportée au cycle suivant. Le housekeeping automatique peut être activé et configuré dans Administration > Housekeeping.

Pour supprimer les données laissées par des objets supprimés, le processus housekeeper s'appuie sur des tâches issues de la table housekeeper, qui est alimentée chaque fois qu'un objet est supprimé. Par exemple, lorsque vous supprimez un hôte, Zabbix supprime également ses éléments, mais pas leur historique, leurs tendances ni leurs problèmes. À la place, des déclencheurs de base de données alimentent la table housekeeper avec des tâches composées des champs suivants :

housekeeperid - ID de la tâche
object - type d'objet (0 - élément; 1 - déclencheur; 2 - service; 3 - hôte découvert; 4 - service découvert)
objectid - ID de l'objet (aide le housekeeper à trouver les données liées à l'objet)

Par exemple, la suppression d'un hôte avec deux éléments et un déclencheur remplit la table housekeeper comme suit :

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

Les déclencheurs de base de données alimentent la table housekeeper sans vérifier la présence de données liées à l'objet ; cette vérification est effectuée par le processus housekeeper.

Chaque tâche entraîne une ou plusieurs opérations housekeeper qui dépendent du type d'objet :

Pour les éléments (y compris les règles LLD) - supprime les données de toutes les tables d'historique et de tendances (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint) qui contiennent des valeurs pour ces éléments. Vérifie également la table problems et supprime les événements internes obsolètes associés à ces éléments.
Pour les déclencheurs - vérifie les tables liées aux événements (problem, event_symptom, event_recovery, events) et supprime les événements obsolètes associés à ces déclencheurs, puis notifie également le processus service manager des événements supprimés.

Un processus distinct trigger housekeeper gère une tâche plus restreinte: la suppression des problèmes et des événements qui n'ont pas de déclencheur source connu. Sa fréquence d'exécution est contrôlée par ProblemHousekeepingFrequency.

Tant que la procédure de housekeeping des déclencheurs n'a pas démarré, 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 ou 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.

Pour les services - vérifie la table problems et supprime les événements de service obsolètes, ainsi que les problèmes de service obsolètes, les résolvant ainsi au moment du housekeeping.
Pour la découverte réseau - supprime les événements de découverte obsolètes de la table problems.

Le housekeeper supprime uniquement les événements qui ne sont pas associés à des problèmes. Par exemple, un événement de problème/rétablissement obsolète ne sera pas supprimé s'il est associé à un problème ouvert. Lorsque le housekeeper supprime des entités obsolètes, il supprime d'abord les problèmes, puis les événements.

Les tables utilisant le mode partition (tables partitionnées TimescaleDB) sont ignorées ; seules les tables utilisant le mode regular sont traitées.

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