Régler Nagios® pour des performances
maximales
Introduction
Maintenant que vous avez pu installer et lancer Nagios®, vous
voulez savoir comment le régler plus finement… Voici quelques
points à prendre en compte pour optimiser Nagios®. Faites moi
savoir si vous en trouvez d’autres…
Trucs et astuces d’optimisation :
- Utilisez des changements d’état agrégés. En activant
la consolidation des changements d’état (grâce au paramètre
aggregate_status_updates),
vous réduirez considérablement la charge sur votre hôte de
supervision, car il n’essaiera pas constamment de mettre à jour
le journal des états.
Ceci est particulièrement vrai si vous supervisez un grand
nombre de services. La principale contrepartie lorsque vous
agrégez les changements d’état est que les modifications d’état
des hôtes et des services ne sont pas immédiatement répliquées
dans le fichier d’état. Ceci peut vous poser problème, ou
pas.
- Utilisez un disque virtuel [NdT : ramdisk] pour
conserver les données d’état. Si vous utilisez le journal des états standard et
que vous n’utilisez pas l’agrégation des changements
d’état, pensez à mettre le répertoire où le journal des états
est stocké sur un disque virtuel en mémoire. Cela accélérera
pas mal les choses (à la fois pour le programme principal et
les CGI) parce que cela évite beaucoup d’interruptions et
d’accès au disque.
- Vérifiez la latence des services pour déterminer la
meilleure valeur pour le nombre maximal de contrôles en
parallèle. Nagios® peut restreindre le nombre maximal de
contrôles de service exécutés en parallèle à la valeur que vous
spécifiez dans le paramètre max_concurrent_checks.
Cela vous permet de gérer la charge que Nagios® impose à votre
hôte de supervision, mais cela peut aussi ralentir le
traitement. Si vous notez des latences importantes (> 10 ou
15 secondes) pour la majorité de vos contrôles de service (via
le CGI d’informations
complémentaires), vous privez sans doute Nagios® des
contrôles dont il a besoin. Ce n’est pas la faute de Nagios® -
c’est la vôtre. Dans des conditions idéales, tous les contrôles
de service ont une latence de 0, ce qui signifie qu’ils sont
exécutés au moment précis où ils ont été ordonnancés. Ceci dit,
il est normal que certains contrôles aient de petites latences.
Je recommanderais de doubler la valeur que propose Nagios® pour
le nombre minimal de contrôles en parallèle, fournie lorsque
Nagios® est lancé avec le paramètre -s. Continuez à
augmenter cette valeur tant que la latence moyenne pour vos
services reste assez basse. Vous trouverez plus d’informations
sur l’ordonnancement des contrôles de service ici.
- Utilisez des contrôles passifs à chaque fois que c’est
possible. La surcharge induite par le traitement des
résultats des contrôles passifs de
service est bien moindre que celle des contrôles actifs
"normaux", donc prenez cette information en compte si vous
supervisez de nombreux services. Notez que les contrôles
passifs de service ne sont réellement utiles que si une
application externe réalise une partie de la supervision ou
produit des rapports ; si c’est Nagios® qui réalise tout le
travail, ceci ne changera rien.
- Evitez l’utilisation des plugins interprétés.
L’utilisation de plugins compilés (C/C++, etc.) réduira
significativement la charge de votre hôte de supervision par
rapport aux scripts interprétés (Perl, etc.). Si les scripts
Perl ou autres sont faciles à écrire et fonctionnent bien, le
fait qu’ils soient compilés/interprétés à chaque exécution peut
augmenter considérablement la charge de votre hôte de
supervision lorsque vous avez de nombreux contrôles de service.
Si vous souhaitez utiliser des plugins Perl, essayez de les
compiler en vrais exécutables grâce à perlcc(1) (un utilitaire
qui fait partie de la distribution Perl standard) ou essayez de
compiler Nagios® avec un interpréteur Perl intégré (voir
ci-dessous).
- Utilisez l’interpréteur Perl intégré. Si vous
utilisez de nombreux scripts Perl pour les contrôles de
service, etc., vous vous apercevrez sans doute qu’en compilant
Nagios® avec un interpréteur Perl intégré vous accélérez les
traitements. Pour compiler l’interpréteur Perl intégré, vous
devez ajouter le paramètre --enable-embedded-perl au
script de configuration [NdT : ./configure] avant de compiler
Nagios®. De même, si vous ajoutez le paramètre
--with-perlcache, la version compilée de tous les
scripts Perl exécutés par l’interpréteur Perl intégré sera mise
en cache pour réutilisation.
- Optimisez les commandes de contrôle d’hôte. Si vous
contrôlez l’état des hôtes avec le plugin check_ping, vous vous
apercevrez que ces contrôles se font bien plus vite en les
éclatant. Plutôt que de spécifier une valeur de 1 pour le
paramètre max_attempts dans la définition de l’hôte et
de dire au plugin check_ping d’envoyer 10 paquets ICMP à
l’hôte, il est bien plus rapide de passer max_attempts à 10 et
de n’envoyer qu’un paquet ICMP à chaque fois. Ceci est dû au
fait que Nagios® peut souvent déterminer l’état d’un hôte après
n’avoir exécuté le plugin qu’une fois, il vaut donc mieux que
le premier contrôle soit le plus rapide possible. Cette méthode
présente des inconvénients dans certaines situations (c.-à-d.
que les hôtes lents à répondre peuvent être considérés comme
hors service), mais vous aurez des contrôles d’hôte plus
rapides si vous l’utilisez. Vous pouvez aussi utiliser un
plugin plus rapide (c.-à-d. check_fping) dans le paramètre
host_check_command plutôt que check_ping.
- Ne planifiez pas une vérification régulière des
hôtes. Il ne faut PAS planifier des vérifications
régulières d’hôtes à moins que ce ne soit absolument
nécessaire. Il n’y a pas beaucoup de raisons de faire cela, car
les vérifications d’hôtes sont effectuées à la demande lorsque
c’est nécessaire. Pour désactiver la vérification régulière
d’un hôte, mettez 0 à la directive check_interval dans
la définition d’hôte. Si
vous avez besoin de vérifier régulièrement les hôtes, essayez
de mettre un intervalle de vérification plus grand et vérifiez
que vos vérifications sont optimisées (voir plus haut).
- N’utilisez pas le contrôle agressif des hôtes. Sauf
si Nagios® a du mal à identifier les rétablissements d’hôte, je
recommanderais de ne pas activer le paramètre use_aggressive_host_checking.
Quand cette option est désactivée, les contrôles s’exécutent
beaucoup plus vite, accélérant le traitement des résultats de
contrôles de service. Cependant, les rétablissements d’hôtes
peuvent être manqués en certaines circonstances lorsque
l’option est désactivée. Par exemple, si un hôte se rétablit et
que tous les services associés à cet hôte restent dans un état
non-OK (et ne "bagotent" pas entre différents états non-OK),
Nagios® peut ne pas voir que l’hôte s’est rétabli. Certains
utilisateurs peuvent avoir besoin d’activer cette option, mais
ce n’est pas le cas pour la majorité, et je recommanderais de
ne pas l’utiliser si vous n’en avez pas expressément
besoin…
- Augmentez l’intervalle de vérification des commandes
externes. Si vous gérez beaucoup de commandes externes (p.
ex. des vérifications passives dans une supervision distribuée), vous devrez
probablement affecter -1 au paramètre command_check_interval.
Cela forcera Nagios® à vérifier les commandes externes aussi
souvent que possible. C’est important parce que la plupart des
systèmes ont une petite taille de tampon pour les tubes de
redirections [NdT : pipe] (c.-à-d. 4 Ko). Si Nagios® ne lit pas
les données depuis le tube le plus rapidement possible,
l’application qui écrit dans le fichier de commandes externes
(p. ex. le démon NSCA) se
bloquera et attendra jusqu’à ce qu’il y ait assez d’espace
libre dans le tube pour écrire ses données.
- Optimisez le matériel pour des performances
maximales. La configuration matérielle va affecter
directement les performances de votre système d’exploitation,
et donc celles de Nagios®. L’amélioration principale que vous
puissiez réaliser concerne les disques durs. La vitesse du
processeur et la mémoire affectent bien évidemment les
performances, mais les accès disque seront votre goulet
d’étranglement le plus fréquent. Ne stockez pas les plugins, le
journal des états, etc. sur des disques lents (c.-à-d. des
vieux disques IDE ou des montages NFS). Si vous en avez,
utilisez des disques UltraSCSI ou des disques IDE rapides. Une
remarque importante pour les utilisateurs de IDE/Linux : bien
des installations de Linux n’essaient pas d’optimiser les accès
au disque. Si vous ne changez pas les paramètres d’accès au
disque (en utilisant un utilitaire comme hdparam), vous
perdrez beaucoup des fonctionnalités améliorant la
vitesse des nouveaux disques IDE.