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.

3 commentaires:

  1. Pourquoi avoir utilisé la version 1.2.4 et non la dernière, 1.2.6 ?
    Y aurait-il des problèmes avec celle-ci ?
    Même Debian a fini par intégrer la 1.2.6 dans sid.

    http://labs.consol.de/nagios/mod-gearman/#_download
    http://packages.debian.org/source/sid/mod-gearman

    RépondreSupprimer
  2. @SurcouF : j'avais commencé à rédiger et préparer mon test sur la version 1.2.4. Entre temps la version 1.2.6 est sortie mais au vu des évolutions, je n'ai trouvé nécessaire de changer de version.

    De toute façon, je vais sûrement reparler de gearman puisque j'utilise la version 1.2.6 sur notre machine nagios de recette. Une fois que j'aurai quelques éléments, j'essaierai de faire quelques retours sur le sujet.

    RépondreSupprimer
  3. Ce commentaire a été supprimé par l'auteur.

    RépondreSupprimer