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 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.
   
   
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é 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 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.
   
   
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 (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.
   
   
8. 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).
   
   
9. 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...
   
   
10. 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.
    
    
11. 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.