[comment]: # ({cbb57ea2-cbb57ea2})
# 1 Serveur

[comment]: # ({/cbb57ea2-cbb57ea2})

[comment]: # ({d54fc79c-0e549571})
#### Aperçu

Le serveur Zabbix est le processus central du logiciel Zabbix.

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.

[comment]: # ({/d54fc79c-0e549571})

[comment]: # ({c20247df-c20247df})
#### Exécution du serveur

[comment]: # ({/c20247df-c20247df})

[comment]: # ({ec500727-1314fd6f})
##### 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 :

```bash
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 :

```bash
/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

[comment]: # ({/ec500727-1314fd6f})

[comment]: # ({3563f7d5-bbb4c5d8})
##### 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 :

```bash
zabbix_server
```

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

```bash
-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 :

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

[comment]: # ({/3563f7d5-bbb4c5d8})

[comment]: # ({4836c205-a339702b})
##### 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[=<section>]`|Collecte des informations de diagnostic dans le fichier journal du serveur.|`historycache` - statistiques du cache d'historique;<br>`valuecache` - statistiques du cache de valeurs;<br>`preprocessing` - statistiques du gestionnaire de prétraitement;<br>`alerting` - statistiques du gestionnaire d'alertes;<br>`lld` - statistiques du gestionnaire LLD;<br>`locks` - liste des mutex (vide sur les systèmes *BSD*);<br>`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.<br>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).<br>Les [suffixes de temps](/manual/appendix/suffixes) 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.<br>Si aucune cible n'est spécifiée, la configuration de tous les proxy est rechargée.|
|`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](/manual/web_interface/frontend_sections/administration/housekeeping).<br>Ignoré si la procédure de housekeeping est déjà en cours.| |
|`trigger_housekeeper_execute`|Démarre la procédure de housekeeping des déclencheurs.<br>Ignoré si la procédure de housekeeping des déclencheurs est déjà en cours.<br>Jusqu'à ce que la procédure de housekeeping des déclencheurs soit lancée, les problèmes causés par des déclencheurs supprimés entre-temps peuvent encore générer des problèmes de service et leur être attribués. Si votre environnement implique de nombreuses [règles de calcul d'état](/manual/it_services/service_tree#service-configuration) 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`](/manual/appendix/config/zabbix_server#problemhousekeepingfrequency).| |
|`log_level_increase[=<target>]`|Augmente le niveau de journalisation, affecte tous les processus si aucune cible n'est spécifiée.<br>Non pris en charge sur les systèmes *BSD*.|**process type** - tous les processus du type spécifié (par exemple, `poller`).<br>Voir tous les [types de processus du serveur](#server-process-types-and-threads).<br>**process type,N** - type de processus et numéro (par exemple, `poller,3`).<br>**pid** - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez la cible sous la forme 'process type,N'.|
|`log_level_decrease[=<target>]`|Diminue le niveau de journalisation, affecte tous les processus si aucune cible n'est spécifiée.<br>Non pris en charge sur les systèmes *BSD*.|^|
|`prof_enable[=<target>]`|Active le profilage.<br>Affecte tous les processus si aucune cible n'est spécifiée.<br>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`)<br>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`.<br>**process type,N** - type de processus et numéro (par exemple, `history syncer,1`).<br>**pid** - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez la cible sous la forme 'process type,N'.<br>**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.<br>Affecte tous les processus si aucune cible n'est spécifiée.|**process type** - tous les processus du type spécifié (par exemple, `history syncer`).<br>Types de processus pris en charge comme cibles de profilage : voir `prof_enable`.<br>**process type,N** - type de processus et numéro (par exemple, `history syncer,1`).<br>**pid** - identifiant de processus (`1` à `65535`). Pour des valeurs plus grandes, spécifiez la cible sous la forme 'process type,N'.|

[comment]: # ({/4836c205-a339702b})

[comment]: # ({bd45cfce-1cb7f51c})
Exemple d'utilisation du contrôle à chaud pour recharger le cache de configuration du serveur :

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

Exemples d'utilisation du contrôle à chaud pour recharger la configuration du proxy :

```bash
# Recharger la configuration de tous les proxies :
zabbix_server -R proxy_config_cache_reload
    
# Recharger la configuration de Proxy1 et Proxy2 :
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2
```

Exemples d'utilisation du contrôle à chaud pour collecter des informations de diagnostic :

```bash
# 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 à chaud pour recharger le cache SNMP :

```bash
zabbix_server -R snmp_cache_reload
```

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

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

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

Exemples d'utilisation du contrôle à chaud pour modifier le niveau de journalisation :

```bash
# 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 de 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 :

```bash
zabbix_server -R ha_set_failover_delay=10s
```

[comment]: # ({/bd45cfce-1cb7f51c})

[comment]: # ({141af812-b4f10179})
##### 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](/manual/installation/install) 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](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.

[comment]: # ({/141af812-b4f10179})

[comment]: # ({822335b2-0a81f475})
##### Fichier de configuration

Consultez les options du [fichier de configuration](/manual/appendix/config/zabbix_server) pour plus de détails sur la configuration de `zabbix_server`.

[comment]: # ({/822335b2-0a81f475})

[comment]: # ({5d50d9d1-49247ffc})
##### 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.

[comment]: # ({/5d50d9d1-49247ffc})

[comment]: # ({c6db57fa-9f05badb})
#### 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 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 du collecteur 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 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 collecte asynchrone pour les vérifications SNMP avec un thread de travail (éléments `walk[OID]` et `get[OID]` uniquement) ;
-   `snmp trapper` - récepteur de 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, 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` - 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.

Depuis Zabbix 7.0.22, 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](/manual/config/items/itemtypes/internal) interne `zabbix[process,<type>,<mode>,<state>]`.

[comment]: # ({/c6db57fa-9f05badb})

[comment]: # ({56afbd4a-cdd68340})
#### 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

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

[comment]: # ({/56afbd4a-cdd68340})

[comment]: # ({eef646bb-982e2546})
#### 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.

[comment]: # ({/eef646bb-982e2546})