Affichage des articles dont le libellé est performance. Afficher tous les articles
Affichage des articles dont le libellé est performance. Afficher tous les articles

mardi 20 mars 2012

Quelques tests du mod_gearman avec nagios

J'ai dernièrement travaillé sur la mise en place d'une nouvelle infra nagios se basant sur une Redhat EL5.5 à la place de ma zone Solaris (youpi ! enfin du Linux sur notre infra !). A cette occasion, j'ai voulu voir ce que donné le mod gearman. Avant de le mettre en production, je l'ai activé sur mon poste (Debian/Kubuntu). J'en décris ici les principales étapes ainsi que les résultats de quelques tests.

Compilation

Ici, rien de très compliqué, il faut récupérer la dernière version (1.2.4 au moment de la rédaction de l'article mais la 1.2.6 est sortie entre temps) à l'adresse suivante : http://labs.consol.de/wp-content/uploads/2010/09/mod_gearman-1.2.4.tar.gz
Avant compilation, installons quelques pré-requis :
apt-get install gearman libgearman-dev
Vient ensuite le temps de la compilation :
# Décompression
tar xfv mod_gearman-1.2.4.tar.gz && cd mod_gearman-1.2.4
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
make install

Intégration de gearman dans nagios

De là, vous devriez obtenir un binaire /usr/lib/mod_gearman/mod_gearman.o que vous pouvez maintenant référencer de la manière suivante dans votre fichier /etc/nagios3/nagios.cfg :
broker_module=/usr/lib/mod_gearman/mod_gearman.o localhostgroups=local-server server=localhost:4730 key=Found@nor1g1nalK3y$ eventhandler=yes services=yes hosts=yes
Ici, il faut surtout noter les points suivants :
  • L'option localhostgroups donne le nom des groupes de machine sur lesquelles nous ne déléguerons pas les appels. Il est de bon goût d'y mettre les machines de votre infra nagios afin d'être sûr de détecter les problèmes sur vos services gearman ;
  • L'option server donne l'adresse d'écoute du démon gearman ;
  • L'option key permettant de gérer le chiffrement des communications entre les process gearman ;
  • Enfin les options eventhandler=yes services=yes hosts=yes permettant d'indiquer ce que nous pouvons faire faire à nos workers gearman.
Il  ne nous reste plus qu'à lancer les workers gearman et faire recharger la configuration à notre moteur nagios :
/etc/init.d/mod_gearman_worker start
Starting mod_gearman_worker...OK
/etc/init.d/nagios3 reload
 * Reloading nagios3 monitoring daemon configuration files nagios3

Lancement d'un petit bench

Maintenant que notre conf est prête, voyons l'impact de gearman sur le fonctionnement de notre moteur nagios. Tout d'abord, un test en désactivant gearman pour avoir une idée de la capacité native de notre moteur nagios.

A propos de la machine et du bench

Rien de particulier à signaler, il s'agit d'un processeur quadri-coeur (AMD Phenom(tm) II X4 965) avec 4 Go de mémoire.
Concernant la conf nagios du bench, elle consiste à créer des fichiers de configuration contenant les éléments suivants :
define host{
        use                     generic-host
        process_perf_data       0
        host_name               @HOST@
        alias                   @HOST@
        address                 127.0.0.1
        }

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       @HOST@
        service_description             dummy1
        check_interval                  1
        check_command                   return-ok
}
[...]

Sans mod_gearman

Voici grosso modo les temps forts au niveau du changement de conf :
Heurenb machinesnb servicesinterval
20h4540056005min
20h5540056001min
21h2560084001min
21h40800112001min

Tout ceci a entraîné le comportement suivant au niveau de la machine de bench :
  • Latence du moteur nagios :
  •  Consommation CPU de la machine

La consommation avoisine en pointe les 92 % avec une moyenne - pour la fin du test - dans les 75%. La latence se situe dans les 500ms en fin de test.

Avec mod_gearman

Passons maintenant la même configuration avec gearman actif. Tout d'abord les évènements du bench :
Heurenb machinesnb servicesinterval
22h0040056001min
22h2060084001min
22h40800112001min
23h021000140001min
23h221200168001min

Et maintenant le comportement du serveur pendant cette même période :
  • Latence du moteur nagios :
  • Consommation CPU :

Non seulement la consommation CPU n'a jamais dépassé 37 % en pointe (on est plutôt à 25% de moyenne) mais en plus, on a pu faire 50 % de tests en plus sans impact particulier au niveau de la machine et en gardant une latence inférieur à 400ms.

Pour conclure ...

Comme on peut le voir, l'utilisation de gearman fait grandement baisser la consommation CPU de notre serveur. D'autant plus que gearman offre également la capacité de distribuer nos surveillances sur plusieurs machines différentes. Vous pouvez également déporter la génération des graphiques sur une autre machine (à l'aide du mode gearman de PNP4Nagios par exemple).

Si vous combinez tout ceci,  nous sommes face à un outil apportant une très grande souplesse à ce vieux moteur nagios. Non seulement vous réduisez votre consommation CPU mais tout en vous laissant la possibilité de distribuer très facilement vos éléments de surveillance/métrologie en fonction de vos besoins.

Pour aller plus loin, je vous conseille de faire un tour sur le site de gearman qui présente pas mal de possibilité d'architecture.

mercredi 9 novembre 2011

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) :
sudo apt-get install rrdcached
Et regardons si ce dernier est bien lancé :
$ /etc/init.d/rrdcached status
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
Tout 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 :
RRD_DAEMON_OPTS = unix:/var/run/rrdcached.sock
Attendons 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 !

mardi 13 septembre 2011

Optimisation du couple nagios/PNP4Nagios

Description de l'installation

J'utilise depuis maintenant plusieurs années un moteur nagios sur notre infra pour avoir un suivi de ce qu'il se passe sur nos serveurs.

Au début, nous avions axé notre déploiement sur la partie serveur d'application Java (à base de WebLogic). Nous avons très rapidement activé l'utilisation du moteur de base de données ndo2db. Par la suite nous avons intégré environ 60 serveurs sous cette surveillance pour un total d'environ 600 services. Les choses sont restés en l'état en raison de la machine que nous utilisions qui était particulièrement lente et pauvre en IO disque (pour les plus curieux, il s'agissait d'un Sunfire V210 avec un bi-processeur Ultrasparc III@1Ghz et 2 Go de mémoire).

Il y'a de ça un an et demi, nous avons échangé notre vieille machine poussive contre une machine Solaris flambant neuve (à base de M5000). De là, j'ai profité pour changer nos outils d'autant que je n'étais pas particulièrement content de ndo2db. C'est à cette occasion que j'ai mis en place la toute dernière version de PNP4Nagios en version 0.6 (que j'avais testé en version béta quelques temps auparavant).

De là, j'ai découvert le super système de template de PNP4nagios (cf cet article) et j'ai commencé à mettre ça en oeuvre sur tous nos éléments vitaux d'infrastructure (apache, oracle, MySQL etc.).

Le mode synchrone de PNP4Nagios étant particulièrement lent, j'ai très vite déployé PNP4Nagios en mode bulk lancé par nagios. Mais, le succès aidant, je suis rapidement passé de 60 à 100 machines puis 200. Comme un SI ne diminue jamais, dernièrement nous sommes arrivé à environ 300 machines pour environ 3000 services. Loin d'être énorme (en tunant la configuration de nagios, on parle de configuration montant à 30000 services et plus), les performances du moteur nagios avaient tout de même tendance à se dégrader comme on peut le voir sur le graphique ci-dessous des temps de latence maximum :


On voit ici des temps de latence maximum qui monté à plus de 60 secondes. Même si c'est loin d'être complètement bloquant, ça indique une réactivité beaucoup moins bonne qu'au début du fonctionnement de la plateforme.

C'est donc à ce moment là que j'ai commencé à regarder les optimisations qu'il était possible de faire et notamment l'utilisation de NPCD. J'ai également mis en place le démon de cache RRD. Pour ce dernier j'essaierai d'en parler dans un autre article.

Mise en place de NPCD

La mise en place de NPCD se fait en deux temps : mise en place du démon puis modification de la commande d'insertion des données de performance dans PNP4Nagios. Ci-dessous un schéma extrait du site de PNP4Nagios expliquant le fonctionnement du démon NPCD :

Pour le lancement du démon NPCD, rien d'extraordinaire, il suffit simplement de lancer la commande suivante :
/usr/local/pnp4nagios/bin/npcd
On peut ensuite vérifier sa présence sur le serveur :
ps -ef | grep npcd
Le démon se lance en s'appuyant sur le fichier /usr/local/pnp4nagios/etc/npcd.cfg. Ce dernier va contenir toutes les informations sur le comportement que devra adopter le démon. Vous pouvez notamment tuner les éléments suivants :
  • Le temps de pause entre deux checks dans le répertoire de spool ;
  • Le nombre max de process perfdata à lancer en parallèle ;
  • La verbosité de la log.
Une fois NPCD, nous allons maintenant pouvoir basculer l'insertion des données en utilisant un répertoire de spool. Pour se faire, nous allons changer les commandes process-service-perfdata-file et process-host-perfdata-file (en principe dans le fichier /usr/local/etc/nagios/template/commands.cfg). Ces dernières ressemblaient aux lignes suivantes :
define command {
       command_name    process-service-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/service-perfdata
}

define command {
       command_name    process-host-perfdata-file
       command_line    /usr/local/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/pnp4nagios/var/host-perfdata
}
Nous les avons remplacé par les lignes suivantes :
define command {
       command_name    process-service-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/service-perfdata /usr/local/pnp4nagios/var/spool/service-perfdata.$TIMET$
}

define command {
       command_name    process-host-perfdata-file
       command_line    /bin/mv /usr/local/pnp4nagios/var/host-perfdata /usr/local/pnp4nagios/var/spool/host-perfdata.$TIMET$
}
Il s'agit simplement de substituer l'appel direct à la commande process_perfdata.pl de PNP4Nagios par un déplacement de fichier dans un répertoire. Pas grand chose me direz-vous mais nous allons vite voir que ce petit changement aura des conséquences très intéressante au niveau de nagios.

Résultat de l'optimisation

Et il se trouve que cette modification a eu un énorme impact sur les performances. Pour preuve un état du temps de latence moyen maximum :

On peut voir que nous avons gagné en stabilité au niveau des temps de réponse max et surtout que ces derniers restent largement en dessous les 5 secondes (sauf exceptionnellement mais rien à voir avec le comportement précédent).