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.
Avant compilation, installons quelques pré-requis :
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.gzAvant compilation, installons quelques pré-requis :
apt-get install gearman libgearman-devVient 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=yesIci, 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.
Tout ceci a entraîné le comportement suivant au niveau de la machine de bench :
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.
Et maintenant le comportement du serveur pendant cette même période :
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 :
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.
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.
