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 :

Heure	nb machines	nb services	interval
20h45	400	5600	5min
20h55	400	5600	1min
21h25	600	8400	1min
21h40	800	11200	1min

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 :

Heure	nb machines	nb services	interval
22h00	400	5600	1min
22h20	600	8400	1min
22h40	800	11200	1min
23h02	1000	14000	1min
23h22	1200	16800	1min

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.