Optimisation de PNP4Nagios avec RRDcached
Suite à l'article sur l'utilisation du démon NPCD, j'ai voulu voir quel pourrait être l'impact de la mise en place du démon RRDCached sur le fonctionnement de PNP4Nagios. Pour se faire, il faut bien comprendre à quoi sert ce fameux démon.
Pour cela, il faut revenir sur le fonctionnement de PNP4Nagios à savoir de prendre un grand nombre de métrique et d'alimenter au fur et à mesure un grand nombre de petit fichier : les fichiers RRD. Au delà d'un certain nombre de service, nous pouvons nous retrouver avec une machine qui fait énormément d'IO et qui du coup n'a plus le temps de mettre à jour certaines métriques (mécanisme de timeout de PNP4Nagios). Nous voyons donc qu'au delà un certain seuil, PNP4Nagios peut retomber sur tous les travers classiques des infrastructures de surveillance : consommer de la puissance CPU et être lent (qui a soufflé le nom de NDO utils ?). Le démon RRDCached prend ici tout son sens. En effet, ce dernier va buffuriser les mises à jours RRD au lieu de les faire unitairement réduisant grandement les IO sur notre serveur nagios.
Pour mieux comprendre, prenons le cas d'un serveur nagios remontant en moyenne 10 métriques par services. Si vous êtes comme moi et que vous avez explosé vos fichiers RRD en n fichiers pour chaque services, vous aurez un fichier par métrique. Si nous scruptons toutes les 5 minutes nos différents services (toujours en moyenne), nous nous retrouvons à mettre à jour 10 fichiers pour chaque test de service nagios. Si on reporte ce chiffre sur 1 heure, nous aurons donc environ 120 écritures sur une heure. Si vous multipliez tout ceci par le nombre de service présent sur vos machines (on va dire 5000), vous vous retrouvez à faire environ 600000 écritures par heure. Si vous ajoutez à cela que votre serveur faire appel à des métriques qui sont plus régulière (toutes les 2 minutes voir toute les minutes), vous pouvez commencer à avoir des problèmes.
RRDCached, en s'intercallant entre les outils RRD et les écritures sur le disque, va regrouper ces dernières et ainsi mieux exploiter les capacités de la machine. Imaginons que ce dernier procéde à une buffurisation des écritures sur 1/2 heure, vous diviserez par 6 vos IOs pour des services scruptant toutes les 5 minutes. Ce chiffre pouvant monter à 30 pour des services remontant des métriques toutes les minutes.
Voyons maintenant comment mettre en oeuvre ce démon.
NB : Par la suite, il est évident que je considérerai que PNP4Nagios sera configuré en mode NPCD (cf mon article sur la configuration de PNP4Nagios en mode NPCD) et surtout qu'il utilisera le module RRDs de perl pour faire ses mise à jour (cf mon article sur le sujet).
Installons tout d'abord notre démon rrdcached (sous Debian ou ubuntu) :
Modifions maintenant la configuration de PNP4Nagios (fichier config_local.php qu'il faudra créer s'il n'existe pas) afin de lui préciser le pipe nommé de notre démon de cache :
Vous pourriez vous dire que le fait de vider le cache de notre démon avant de pouvoir consulter nos graphiques est une perte de temps. Effectivement, ce comportement sera peu avantageux pour les fichiers RRDs que nous voudrons consulter. En revanche, il sera avantageux pour les milliers d'autres qui pourront continuer à être buffurisé.
ATTENTION !!! Dorénavant, votre démon RRDcached est un élément vitale de votre infrastructure. Je vous recommande chaudement de le surveiller avec votre moteur nagios sous peine de ne plus avoir de mise à jour si ce dernier devait tomber.
Vous allez me dire que tout ça c'est très bien mais vous voudriez savoir si le jeu en vaut la chandelle. Comme généralement les graphiques parlent plus que les chiffres, voici les résultats des temps de réponse moyen de PNP4Nagios suite à la mise en place de ce merveilleux plugin (ici sur 1 mois) :
Comme vous pouvez le constater, du jour où le démon a été mis en place, j'ai vu une grosse diminution de l'effet yoyo et surtout une baisse assez importante du temps moyen pour les mise à jour de PNP4Nagios (passage de 9 secondes avec pointe à 70 secondes à une moyenne sans pique autour de 5 secondes). Autant vous dire que tout ceci est une très bonne nouvelle et que je vais pouvoir continuer mon travail de big brother !
Pour cela, il faut revenir sur le fonctionnement de PNP4Nagios à savoir de prendre un grand nombre de métrique et d'alimenter au fur et à mesure un grand nombre de petit fichier : les fichiers RRD. Au delà d'un certain nombre de service, nous pouvons nous retrouver avec une machine qui fait énormément d'IO et qui du coup n'a plus le temps de mettre à jour certaines métriques (mécanisme de timeout de PNP4Nagios). Nous voyons donc qu'au delà un certain seuil, PNP4Nagios peut retomber sur tous les travers classiques des infrastructures de surveillance : consommer de la puissance CPU et être lent (qui a soufflé le nom de NDO utils ?). Le démon RRDCached prend ici tout son sens. En effet, ce dernier va buffuriser les mises à jours RRD au lieu de les faire unitairement réduisant grandement les IO sur notre serveur nagios.
Pour mieux comprendre, prenons le cas d'un serveur nagios remontant en moyenne 10 métriques par services. Si vous êtes comme moi et que vous avez explosé vos fichiers RRD en n fichiers pour chaque services, vous aurez un fichier par métrique. Si nous scruptons toutes les 5 minutes nos différents services (toujours en moyenne), nous nous retrouvons à mettre à jour 10 fichiers pour chaque test de service nagios. Si on reporte ce chiffre sur 1 heure, nous aurons donc environ 120 écritures sur une heure. Si vous multipliez tout ceci par le nombre de service présent sur vos machines (on va dire 5000), vous vous retrouvez à faire environ 600000 écritures par heure. Si vous ajoutez à cela que votre serveur faire appel à des métriques qui sont plus régulière (toutes les 2 minutes voir toute les minutes), vous pouvez commencer à avoir des problèmes.
RRDCached, en s'intercallant entre les outils RRD et les écritures sur le disque, va regrouper ces dernières et ainsi mieux exploiter les capacités de la machine. Imaginons que ce dernier procéde à une buffurisation des écritures sur 1/2 heure, vous diviserez par 6 vos IOs pour des services scruptant toutes les 5 minutes. Ce chiffre pouvant monter à 30 pour des services remontant des métriques toutes les minutes.
Voyons maintenant comment mettre en oeuvre ce démon.
NB : Par la suite, il est évident que je considérerai que PNP4Nagios sera configuré en mode NPCD (cf mon article sur la configuration de PNP4Nagios en mode NPCD) et surtout qu'il utilisera le module RRDs de perl pour faire ses mise à jour (cf mon article sur le sujet).
Installons tout d'abord notre démon rrdcached (sous Debian ou ubuntu) :
sudo apt-get install rrdcachedEt regardons si ce dernier est bien lancé :
$ /etc/init.d/rrdcached statusTout semble aller pour le mieux. Nous allons maintenant configurer le script process_perfdata.pl afin qu'il passe par ce démon pour la mise à jour des fichiers RRD. Pour se faire, nous allons modifier le fichier process_perfdata.cfg et notamment la ligne suivante :
rrdcached (1262) is running.
$ ps -fp 1262
UID PID PPID C STIME TTY TIME CMD
root 1262 1 0 18:46 ? 00:00:00 /usr/bin/rrdcached -l unix:/var/run/rrdcached.sock -j /var/lib/rrdcached/journal
RRD_DAEMON_OPTS = unix:/var/run/rrdcached.sockAttendons un petit peu et allons consulter l'interface de PNP4Nagios. Cette dernière ne devrait plus nous remonter de statistique sur notre moteur PNP4Nagios. Ce comportement est tout à fait normal étant donné que l'interface PHP de PNP4Nagios n'a aucune connaissance de ce nouveau démon. Ce dernier continue donc de s'appuyer sur les fichiers RRD présent alors que ces derniers ne sont plus mis à jour en temps réel.
Modifions maintenant la configuration de PNP4Nagios (fichier config_local.php qu'il faudra créer s'il n'existe pas) afin de lui préciser le pipe nommé de notre démon de cache :
$conf['RRD_DAEMON_OPTS'] = 'unix:/var/run/rrdcached.sock';Dorénavant, le graphique se met bien à jour en temps réel. En effet, en précisant au binaire RRDTool que nous avons un démon de cache, ce dernier va simplement dire au démon de vider ses buffers sur les fichiers RRDs que nous sommes en train de consulter afin qu'il nous fasse profiter des dernières valeurs que ce dernier avait emmagasiné.
Vous pourriez vous dire que le fait de vider le cache de notre démon avant de pouvoir consulter nos graphiques est une perte de temps. Effectivement, ce comportement sera peu avantageux pour les fichiers RRDs que nous voudrons consulter. En revanche, il sera avantageux pour les milliers d'autres qui pourront continuer à être buffurisé.
ATTENTION !!! Dorénavant, votre démon RRDcached est un élément vitale de votre infrastructure. Je vous recommande chaudement de le surveiller avec votre moteur nagios sous peine de ne plus avoir de mise à jour si ce dernier devait tomber.
Vous allez me dire que tout ça c'est très bien mais vous voudriez savoir si le jeu en vaut la chandelle. Comme généralement les graphiques parlent plus que les chiffres, voici les résultats des temps de réponse moyen de PNP4Nagios suite à la mise en place de ce merveilleux plugin (ici sur 1 mois) :
Comme vous pouvez le constater, du jour où le démon a été mis en place, j'ai vu une grosse diminution de l'effet yoyo et surtout une baisse assez importante du temps moyen pour les mise à jour de PNP4Nagios (passage de 9 secondes avec pointe à 70 secondes à une moyenne sans pique autour de 5 secondes). Autant vous dire que tout ceci est une très bonne nouvelle et que je vais pouvoir continuer mon travail de big brother !
