Zabbix Documentation 4.0

Il est très important que le système Zabbix soit correctement réglé pour des performances optimales.

Conseils généraux sur le matériel :

• Utilisez le processeur le plus rapide disponible
• SCSI ou SAS est mieux qu'IDE (les performances des disques IDE peuvent être considérablement améliorées en utilisant l'utilitaire hdparm) et SATA
• 15K RPM est mieux que 10K RPM qui est mieux que 7200 RPM
• Utiliser un stockage RAID rapide
• Utiliser un adaptateur Ethernet rapide
• Avoir plus de mémoire, c'est toujours mieux

• Utilisez la dernière version (stable !) d'un OS
• Exclure les fonctionnalités inutiles du noyau
• Ajuster les paramètres du noyau

De nombreux paramètres peuvent être ajustés pour obtenir des performances optimales.

StartPollers

Règle générale - maintenez la valeur de ce paramètre aussi basse que possible. Chaque instance supplémentaire de zabbix_server ajoute une surcharge connue, parallèlement, le parallélisme est augmenté. Le nombre optimal d'instances est atteint lorsque la file d'attente contient en moyenne un nombre minimal de paramètres (idéalement, 0 à un moment donné). Cette valeur peut être surveillée à l’aide de la vérification interne zabbix[queue].

DebugLevel

La valeur optimale est 3.

DBSocket

MySQL seulement. Il est recommandé d’utiliser DBSocket pour la connexion à la base de données. C'est le moyen le plus rapide et le plus sûr.

C’est probablement la partie la plus importante du réglage de Zabbix. Zabbix dépend fortement de la disponibilité et des performances du moteur de base de données.

• utiliser le moteur de base de données le plus rapide, à savoir MySQL ou PostgreSQL
• utiliser la version stable d'un moteur de base de données
• reconstruisez MySQL ou PostgreSQL à partir de sources pour obtenir des performances maximales
• suivez les instructions de réglage des performances extraites de la documentation MySQL ou PostgreSQL
• pour MySQL, utilisez une structure de table InnoDB
• ZABBIX fonctionne au moins 1.5 fois plus vite (comparé à MyISAM) si InnoDB est utilisé. Ceci est dû au parallélisme accru. Cependant, InnoDB nécessite plus de puissance au niveau du CPU.
• il est vivement recommandé d’optimiser le serveur de base de données pour obtenir les meilleures performances.
• conserver les tables de base de données sur différents disques durs
• 'history', 'history_str, 'items' 'functions', triggers', et 'trends' sont les tables les plus utilisées.
• pour les grandes installations, conserver les fichiers temporaires MySQL dans tmpfs est :
  • MySQL >= 5.5: non recommendé (bug MySQL #58421)
  • MySQL < 5.5: recommendé

Les problèmes liés aux performances de l'interface peuvent être diagnostiqués à l'aide de l'interface en mode debug.

• surveiller uniquement les paramètres nécessaires
• régler 'intervalle de mise à jour' pour tous les éléments. Garder un petit intervalle de mise à jour peut afficher de beaux graphiques, cependant, cela peut surcharger Zabbix
• régler les paramètres pour les modèles par défaut
• régler les paramètres de maintenance
• ne surveillez pas des paramètres qui renvoient la même information.
• éviter l'utilisation de déclencheurs avec une longue période donnée comme argument de fonction. Par exemple, max(3600) sera calculé beaucoup plus lentement que max(60).

Depuis Zabbix 2.2, les processus changent leurs lignes de commande pour afficher l'activité en cours et des statistiques significatives, telles que :

UID        PID  PPID  C STIME TTY      TIME CMD
zabbix22  4584     1  0 14:55 ?    00:00:00 zabbix_server -c /home/zabbix22/zabbix_server.conf
zabbix22  4587  4584  0 14:55 ?    00:00:00 zabbix_server: configuration syncer [synced configuration in 0.041169 sec, idle 60 sec]
zabbix22  4588  4584  0 14:55 ?    00:00:00 zabbix_server: db watchdog [synced alerts config in 0.018748 sec, idle 60 sec]
zabbix22  4608  4584  0 14:55 ?    00:00:00 zabbix_server: timer #1 [updated ​0 hosts, suppressed ​0 events in 0.000472 ​sec, idle 59 sec]
zabbix22  4637  4584  0 14:55 ?    00:00:01 zabbix_server: history syncer #3 [processed 0 values, 0 triggers ​in 0.000036 ​sec, idle 1 sec]
zabbix22  4657  4584  0 14:55 ?    00:00:00 zabbix_server: vmware collector #1 [updated 0, removed 0 VMware services in 0.000004 sec, idle 5 sec]
zabbix22  4670     1  0 14:55 ?    00:00:00 zabbix_proxy -c /home/zabbix22/zabbix_proxy.conf
zabbix22  4673  4670  0 14:55 ?    00:00:00 zabbix_proxy: configuration syncer [synced config 15251 bytes in 0.111861 sec, idle 60 sec]
zabbix22  4674  4670  0 14:55 ?    00:00:00 zabbix_proxy: heartbeat sender [sending heartbeat message success in 0.013643 sec, idle 30 sec]
zabbix22  4688  4670  0 14:55 ?    00:00:00 zabbix_proxy: icmp pinger #1 [got 1 values in 1.811128 sec, idle 5 sec]
zabbix22  4690  4670  0 14:55 ?    00:00:00 zabbix_proxy: housekeeper [deleted 9870 records in 0.233491 sec, idle 3599 sec]
zabbix22  4701  4670  0 14:55 ?    00:00:08 zabbix_proxy: http poller #2 [got 1 values in 0.024105 sec, idle 1 sec]
zabbix22  4707  4670  0 14:55 ?    00:00:00 zabbix_proxy: history syncer #4 [processed 0 values, 0 triggers ​in 0.000039 ​sec, idle 1 sec]
zabbix22  4738     1  0 14:55 ?    00:00:00 zabbix_agentd -c /home/zabbix22/zabbix_agentd.conf
zabbix22  4739  4738  0 14:55 ?    00:00:00 zabbix_agentd: collector [idle 1 sec]
zabbix22  4740  4738  0 14:55 ?    00:00:00 zabbix_agentd: listener #1 [waiting for connection]
zabbix22  4741  4738  0 14:55 ?    00:00:00 zabbix_agentd: listener #2 [processing request]

Le processus principal est une exception. Au lieu de l'activité en cours, la ligne de commande d'origine est affichée. Cela permet de distinguer les processus sur les systèmes comportant plusieurs instances de Zabbix.

Cette fonctionnalité n'est pas implémentée pour Microsoft Windows.

Si le niveau de journalisation est défini sur DebugLevel=4, ces messages d'activité et de statistiques sont également écrits dans le fichier journal.

Sur les systèmes Linux, la commande ps peut être utilisée avec la commande watch pour observer comment fonctionne de Zabbix. Par exemple, pour exécuter la commande ps 5 fois par seconde pour afficher les activités des processus :

watch -n 0.2 ps -fu zabbix

Pour afficher uniquement les processus de proxy et d'agent Zabbix :

watch -tn 0.2 'ps -f -C zabbix_proxy -C zabbix_agentd'

Pour afficher uniquement les processus de syncer d'historique :

watch -tn 0.2 'ps -fC zabbix_server | grep history'

La commande ps produit une sortie large (environ 190 colonnes) car certains messages d'activité sont longs. Si votre terminal a moins de 190 colonnes de texte, vous pouvez essayer

watch -tn 0.2 'ps -o cmd -C zabbix_server -C zabbix_proxy -C zabbix_agentd'

pour afficher uniquement les lignes de commande sans UID, PID, start time, etc.

La commande top peut également être utilisée pour observer les performances de Zabbix. En appuyant sur 'c', appuyez sur top pour afficher les processus avec leurs lignes de commande. Dans nos tests sur Linux, top et atop affichaient correctement les activités changeantes des processus Zabbix, mais htop n'affichait pas les activités en évolution.

Si la commande watch n'est pas installée, un effet similaire peut être réalisé avec

while [ 1 ]; do ps x; sleep 0.2; clear; done

Si la commande watch n'est pas disponible , vous pouvez essayer :

while [ 1 ]; do ps -fu zabbix; sleep 1; clear; done

Par défaut, la commande ps n'affiche pas les activités en cours de modification. Une option consiste à utiliser /usr/ucb/ps à la place. Si la commande watch n'est pas installée, une liste de processus mise à jour périodiquement peut être affichée avec

while [ 1 ]; do /usr/ucb/ps gxww; sleep 1; clear; done

Sous Solaris 11:

• /usr/ucb/ps n'est pas installé par défaut. Vous devrez peut-être installer le package ucb, par exemple : pkg install compatibility/ucb,
• Si le démon Zabbix a été démarré par un utilisateur privilégié, ses activités ne sont pas présentées aux utilisateurs non privilégiés.
• la commande sleep accepte non seulement des secondes entières, mais également des fractions de seconde (par exemple : sleep 0.2).

1. Comment configurer le nombre optimal de processus zabbix