Graphez les statistiques de performance collectées avec MRTG. Vous devriez en effet grapher les quelques statistiques importantes produites avec MRTG pour garder des traces de comment votre installation de Nagios se comporte dans le temps au niveau charge et de comment les changements de configuration l'affectent. Cela devient vraiment, vraiment, vraiment utile quand il s'agit d'optimiser les performances d'une installation Nagios. Les informations sur la façon de le faire se trouvent ici.

Utilisez les trucs et astuces pour les installations de grande dimension. Activer l'option use_large_installation_tweaks peut vous donner de meilleures performances. Lisez plus d'informations sur ce que fait cette option ici.

Désactivez les macros d'environnement. Les macros sont normalement mises à disposition des commandes, contrôles, notifications, etc. comme variables d'environnement. Cela peut devenir un problème sur une installation Nagios de grande dimension parce que cela consomme plus de mémoire et (plus important) plus de CPU. Si vos scripts n'ont pas besoin d'avoir accès aux macros comme variables d'environnement (vous pouvez passer par exemple toutes les macros nécessaires en argument de la ligne de commande), vous n'avez alors pas besoin de cette fonctionnalité. Vous pouvez empêcher de rendre les macros disponibles comme variables d'environnement en utilisant l'option enable_environment_macros .

Fréquence de consolidation des résultats de contrôle. La variable check_result_reaper_frequency détermine la fréquence à laquelle Nagios doit vérifier la présence de résultats de contrôles d'hôtes et de services qui doivent être traités. Le temps maximum qu'il doit passer à traiter ces résultats est déterminé par la variable temps maximum de consolidation (voir ci-dessous). Si votre fréquence de consolidation est trop élevée (pas assez fréquente), vous pourriez voir apparaître des latences importantes dans les contrôles d'hôtes et de services.

Temps maximum de consolidation. La variable max_check_result_reaper_time détermine le temps maximum que le démon Nagios peut passer à traiter les résultats de contrôles d'hôtes et de services avant de pouvoir faire autre chose - comme exécuter de nouveaux contrôles d'hôtes et de services. Une valeur trop élevée peut donner des latences importantes pour les contrôles d'hôtes et de services. Si vous rencontrez des problèmes de latences élevées, ajustez cette variable et vérifiez le résultat de vos réglages. Une nouvelle fois, vous devriez grapher les statistiques avec MRTG pour pouvoir prendre cette décision.

Ajuster la taille du tampon. Vous pouvez avoir à régler la valeur de l'option external_command_buffer_slots . Grapher les statistiques liées au tampon avec MRTG (voir au dessus) est critique pour pouvoir déterminer les valeurs à utiliser pour cette option.

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.

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.

Planifiez une vérification régulière des hôtes. La planification régulière de contrôles d'hôtes peut donner un gain de performance à Nagios. Cela est dû à la façon dont la logique de cache des contrôles fonctionne (voir ci-dessous). Avant Nagios 3, la planification régulière des contrôles d'hôtes pouvait avoir un impact très négatif sur les performances. Ce n'est plus le cas puisque les contrôles d'hôtes sont exécutés en parallèle - tout comme les services. Pour planifier des contrôles réguliers pour un hôte, mettez le paramètre check_interval de la définition d'hôte à une valeur supérieure à 0.

Activer le cache pour les contrôles d'hôtes. À compter de Nagios 3, les contrôles d'hôtes à la demande peuvent bénéficier de cache. Les contrôles d'hôtes à la demande sont déclenchés quand Nagios détecte un changement d'état sur un service. Ces contrôles sont exécutés parce que Nagios veut savoir si l'hôtes associé au service a changé d'état. En activant le cache pour les contrôles d'hôtes, vous pouvez gagner en performance. Dans certains cas, Nagios peut être capable d'utiliser l'état mise en cache d'un hôte, plutôt que de réellement exécuter le contrôle. Cela peut accélérer les choses et réduire la charge du serveur de supervision. Pour mettre en place le cache des contrôles d'hôtes, vous devez ordonnancer des contrôles réguliers de vos hôtes (voir plus haut). Plus d'informations sur le cache pour les contrôles d'hôtes peut être trouvé ici.

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). Les tampons sont utilisés pour conserver les commandes externes lues depuis le fichier de commandes externes (par un thread séparé) avant d'être traitées par le démon Nagios. Si celui-ci reçoit beaucoup de remontées de contrôles passifs, vous pouvez aboutir à une situation où le tampon est toujours plein. Le résultat est que les processus enfant (scripts externes, démon NSCA, etc.)sont bloqués quand ils essayent d'écrire dans le fichier de commandes externes. Je vous recommande fortement de grapher le tampon pour les tubes de redirections en utilisant MRTG et l'utilitaire nagiostats comme décrit ici de façon à voir la consommation moyenne du tampon pour les tubes de redirections de votre installation Nagios.

Optimisez le matériel pour des performances maximales.