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 :

1. Utilisez des changements d'état agrégés. En activant la consolidation des changements d'état (grâce à l'option 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.
   
   
2. 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é (NdT : var/) 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.
   
   
3. Vérifiez les latences 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 recommenderais 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.
   
   
4. 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.
   
   
5. 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).
   
   
6. 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.
   
   
7. 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 (i.e. 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 (i.e. check_fping) dans le paramétre host_check_command plutôt que check_ping.
   
   
8. N'utilisez pas de contrôles agressif des hôtes. Sauf si Nagios a du mal à identifier les rétablissements d'hôte, je recommanderais de ne pas activer l'option use_aggressive_host_checking. Quand cette option est désactivé, 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 expressement besoin...
   
   
9. Augmentez l'interval de vérification des commandes externes. Si vous gérez beaucoup de commandes externes (par exemple des vérifications passives avec la supervision distribuée), vous devrez probablement affecter -1 à la variable 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), par exemple 4Ko. Si Nagios ne lit pas les données depuis le tube le plus rapidement possible, l'application qui ecrit depuis la commande externe (par exemple le plugin NSCA) bloquera et attendra jusqu'à ce qu'il est assez d'espace libre dans le tube pour écrire ses données.
   
   
10. Optimisez le matériel pour des performances maximales Optimize hardware for maximum performance. La configuration matérielle de votre système 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 au disque seront votre goulet d'étranglement le plus fréquent. Ne stockez pas les plugins, le journal des états, etc. sur des disques lents (i.e. 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 IDE/Linux est que 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 fonctionalités améliorant la rapidité des nouveaux disques IDE. (NdT : Voyez cet article pour plus d'informations sur le réglage des performances des disques durs sous Linux.)