Distributed Monitoring Nagios à l'aide de Mod-Gearman

Le Distributed Monitoring de Nagios avec Mod-Gearman nécessite au minimum deux éléments :

• Un serveur qui sera à la fois le serveur Nagios et le serveur de jobs Mod-Gearman ;
• Un worker qui peut être indépendant ou présent sur le serveur de jobs Mod-Gearman.

Mod-Gearman fonctionne de cette façon :

• Un côté job server qui distribuera les jobs et rapatriera les résultats ;
• Et un côté worker qui réalisera les checks sur les hôtes de ses hostgroups.

De manière plus précise, le fonctionnement détaillé est le suivant :

• le serveur de jobs attend d'être contacté par des workers ;
• lorsque les workers contactent le job server , ils s'authentifient auprès de lui, et il les répertorie ;
• le serveur de jobs dispose d'un Event Broker que l'on insère dans Nagios ;
• il remplacera donc la partie de Nagios qui réalise les checks, pour pouvoir les distribuer à sa guise.

Un worker peut avoir plusieurs hostgroups assignés. Pour chaque hostgroup auquel il sera assigné, il prendra les jobs que le serveur de jobs mettra à disposition.

2-1. Côté technique▲

2-2. Côté pratique▲

Avant de parler d'installation et de configuration, apprenons le concept, et le fonctionnement d'un Nagios fonctionnant avec un Mod-Gearman.

Voici un schéma illustrant mon serveur Nagios en production :

On voit ici la façon dont j'ai architecturé mon Nagios pour gérer des clients facilement.

Chaque dossier client qui se trouve dans /etc/nagios3/conf.d/hosts/ contient un fichier de définition de hostgroup, un fichier par machine, et un dernier fichier comprenant les personnes de contact à mailer pour les alertes, et les plages horaires.

Le reste des fichiers de configuration est dans /etc/nagios3/conf.d/.

Ici sont les templates utilisés pour tous les clients, et les templates /contacts /timeperiods utilisés pour notre infrastructure.

J'ai représenté deux workers qui contactent, à travers plusieurs firewalls mon serveur de jobs, qui prend les checks à Nagios et lui restitue les résultats.

Il n'y a pas de modifications à apporter à Nagios pour ainsi dire. Une mention pour chaque hôte lui spécifiant quel worker doit se charger de lui, un Event Broker dans /etc/nagios3/nagios.cfg et c'est tout. Pour le reste c'est de la config de workers.

Pour préparer un serveur de jobs et un worker, il faut suivre quelques étapes cruciales.

Nous avons besoin avant de commencer :

Un serveur Nagios 3.4.1 sur une Debian 7 (la manœuvre ne diffère pas beaucoup selon les OS, juste la façon de compiler qui devrait être différente, mais je n'expliquerai ici que la méthode que j'ai réalisée pour Debian, travaillant exclusivement sur cet OS. Merci Antoine Habran :D ).

Et en bonus : Un worker Raspberry Pi mod. B. (ou sinon un autre PC.).

En bonus, car on peut s'en passer, le job server peut contenir un worker. Mais l'idée c'est de mettre le worker ailleurs sur le Net et le voir contacter notre serveur, pas vrai ?

4-1. Explications▲

4-2. Installation de Mod-Gearman▲

apt-get install libcurl4-gnutls-dev autoconf automake make gcc g++ netcat uuid-dev libltdl7 libltdl-dev libncurses5-dev libevent-dev libboost-dev libboost-graph-dev libboost-iostreams-dev libboost-program-options-dev build-essential libboost-thread-dev libcloog-ppl0

cd /tmp 
wget https://launchpad.net/gearmand/1.2/1.1.9/+download/gearmand-1.1.9.tar.gz tar zxvf gearmand-1.1.9.tar.gz cd gearmand-1.1.9

echo «opt/lib/» /etc/ld.so.conf.d/opt_lib.conf
        ldconfig

./configure -prefix=/opt
        make
        make install

cd /tmp
wget http://labs.consol.de/wp-content/uploads/2010/09/mod_gearman-1.4.2.tar.gz
tar zxvf mod-gearman-1.4.2.tar.gz
cd mod-gearman-1.4.2

./configure --prefix=/opt --with-gearman=/opt --with-user=nagios -with-init-dir=/etc/init.d
make
make install
make install-config

cp ./extras/gearmand-init /etc/init.d/gearmand

chsh nagios
>> /bin/bash
chmod -R 770 /opt/var/log/mod_gearman
chown -R nagios:nagios /opt/var/log/mod_gearman

4-3. Configuration du job server sur le serveur▲

debug=0 
logfile=/opt/var/log/mod_gearman/mod_gearman_neb.log 
server=127.0.0.1:4730 
do_hostchecks=yes 
encryption=yes 
key=Superpasswordquidéchire 
use_uniq_jobs=on 
localhostgroups= 
localservicegroups= 
queue_custom_variable=WORKER 
result_workers=1 
perfdata=no 
perfdata_mode=1 
orphan_host_checks=yes 
orphan_service_checks=yes 
accept_clear_results=no

4-4. Configuration du worker sur le serveur▲

debug=0 
hostgroups=hostgroup1-servers,hostgroup2-servers 
logfile=/opt/var/log/mod_gearman/mod_gearman_worker.log 
server=127.0.0.1:4730 
encryption=yes 
key=Superpasswordquidéchire 
job_timeout=60 
min-worker=5 
max-worker=50 
idle-timeout=30 
max-jobs=1000 
spawn-rate=1 
fork_on_exec=no 
load_limit1=0 
load_limit5=0 
load_limit15=0 
show_error_output=yes 
enable_embedded_perl=on 
use_embedded_perl_implicitly=off 
use_perl_cache=on 
p1_file=/opt/share/mod_gearman/mod_gearman_p1.pl 
workaround_rc_25=off

4-5. Configuration de Nagios▲

/etc/init.d/nagios3 stop

Broker_module=/opt/lib/mod_gearman/mod_gearman.o config=/opt/etc/mod_gearman_neb.conf

Il nous est nécessaire d'avoir une configuration orientée hostgroups pour mettre en place votre architecture distribuée.

Je vais illustrer cette configuration comme sur le schéma du début du document. On va donc créer deux hostgroups : hostgroup1-servers et hostgroup2-servers :

touch /etc/nagios3/conf.d/hosts/client1/hostgroup1.cfg
touch /etc/nagios3/conf.d/hosts/client2/hostgroup2.cfg

Ensuite on va ajouter des machines, il nous faut au moins une machine par hostgroup.

touch /etc/nagios3/conf.d/hosts/client1/serveurnagios.cfg
touch /etc/nagios3/conf.d/hosts/client2/serveurlambda.cfg

Il nous faut un worker sur le site distant, disons que le client2 est a 200Km d'où je me trouve, je me rends sur place, je déploie un worker, dont on parlera plus bas, et je ne m'en occupe plus, mais il faut le surveiller aussi le petit coquin.

touch /etc/nagios3/conf.d/hosts/client2/worker.cfg

Voici le fichier contenu de mon fichier hostgroup1.cfg :

define hostgroup{ 
hostgroup_name hostgroup1-servers 
alias mes serveurs du hostgroup 1 
members hostgroup1-serveurnagios 
} 
 
define hostextinfo{ 
hostgroup_name hostgroup1-servers 
notes serveurs du hostgroup1 
icon_image base/uneimage.png 
icon_image_alt hostgroup1 logo 
vrml_image base/uneimage.png 
statusmap_image base/uneimage.png 
}

Ici rien de spécial, comme vous le voyez. Le hostgroup est défini normalement.

Voici un fichier pour l'hôte « hostgroup1-serveurnagios » /etc/nagios3/conf.d/hosts/hostgroup1/serveurnagios.cfg.

define host{ 
       use generic-host 
       host_name hostgroup1-serveurnagios 
       alias hostgroup1-serveurnagios 
       address 127.0.0.1 
       _WORKER hostgroup_hostgroup1-servers 
       } 
 
define service{ 
       use generic-service 
       host_name hostgroup1-serveurnagios 
       check_command check_ssh 
       }

Voilà un fichier d'hôte lambda, pour aller avec le fichier de hostgroup correspondant. J'ai mis un service lambda aussi, un check ssh.

Le second hostgroup sera comme suit :

define hostgroup{ 
hostgroup_name hostgroup2-servers 
alias mes serveurs du hostgroup 2 
members hostgroup2-serveurlambda,hostgroup2-worker 
} 
 
define hostextinfo{ 
hostgroup_name hostgroup2-servers 
notes serveurs du hostgroup2 
icon_image base/uneimage2.png 
icon_image_alt hostgroup2 logo 
vrml_image base/uneimage2.png 
statusmap_image base/uneimage2.png 
}

Voici le fichier hôte de la machine serveur lambda :

define host{ 
       use generic-host 
       host_name hostgroup2-serveurlambda 
       alias hostgroup2-serveurlambda 
       address 192.168.1.200 
       _WORKER hostgroup_hostgroup2-servers 
       } 
  
define service{ 
       use generic-service 
       host_name hostgroup2-serveurlambda 
       check_command check_ssh 
       }

Et le fichier de config du worker.

define host{ 
       use generic-host 
       host_name hostgroup2-worker 
       alias hostgroup2-worker 
       address 192.168.1.100 
       _WORKER hostgroup_hostgroup2-servers 
       } 
 
define service{ 
       use generic-service 
       host_name hostgroup2-worker 
       check_command check_ssh 
       }

5-1. Configuration du worker présent sur le serveur▲

hostgroups=

hostgroups=hostgroup1-servers

D'abord, on va démarrer Nagios, Gearmand, ensuite le worker Mod-Gearman.

/etc/init.d/nagios3 start
/etc/init.d/gearmand start

Et ensuite :

su nagios -c '/etc/init.d/mod_gearman_worker start'

Le worker doit être démarré par l'utilisateur Nagios pour fonctionner. Donc on l'exécute avec la commande su et l'option -c .

Pour faciliter les choses, éditez /etc/rc.local et ajoutez les deux lignes :

/etc/init.d/gearmand start
su nagios -c '/etc/init.d/mod_gearman_worker start'

Et comme ça, à chaque reboot, vos services seront exécutés comme il se doit.

Là tout devrait tourner proprement, et les checks pour votre serveur Nagios être exécutés, pas les autres.

Le worker du hostgroup2 et le serveur lambda du hostgroup2 qui n'existent d'ailleurs pas ne devraient pas rendre de critical, car ils ne sont pas pris en charge. Il vous faudra ajouter un worker avec la ligne :

Hostgroups=hostgroup2-servers

On peut évidemment mettre plusieurs workers pour un seul hostgroup, il suffit de les mettre avec la même configuration.

Ce que je trouve magique avec l'architecture distribuée Gearman, c'est qu'elle peut être utilisée avec des Raspberry… Si vous ne connaissez pas, vous devriez vraiment vous pencher sur ces machines merveilleuses !

Pour réaliser un worker sur un Raspberry Pi Mod. B , rien de plus simple. Une fois l'installation du Raspbian faite sur votre carte SD, lancez votre Raspberry, configurez le avec le raspi-config, et ensuite mettez le à jour (apt-get update , apt-get upgrade).

Ensuite, on tape :

apt-get install mod-gearman-worker

Il va s'installer, et vous n'aurez qu'à le configurer basiquement pour qu'il soit pris en charge.

Exemple de config : /etc/mod-gearman-worker/worker.conf

server=ippublique:4730 
key= Superpasswordquidéchire 
hostgroup=hostgroup2-servers 
encryption=yes 
job_timeout=60 
p1_file=/usr/share/mod-gearman/mod_gearman_p1.pl

Ouais… C'est tout !

Par défaut il va gérer le worker comme un petit chef, besoin de rien de plus que ceci.

Le serveur, le password, le(s) hostgroup(s) , l'encryption, et par contre…

SURTOUT spécifier ce job_timeout=60 (60 ou ce qui conviendra à vos checks, si vous avez par exemple un check qui met deux minutes à rendre son résultat, montez la valeur).

Si vous ne le faites pas et qu'un check « casse » en route, suite à un souci de connexion ou autre, votre worker attendra ad vitam æternam le résultat , et sera par conséquent… planté ! Ça ne vous ferait pas plaisir de faire 200 km en voiture pour débrancher et rebrancher un PC grand comme une carte de crédit, pas vrai ? (Comment ça, ça sent le vécu ? Je ne vous perm… oui c'est vrai.)

Donc, créez une machine virtuelle ou autre, sur une range inaccessible par votre serveur Nagios, avec l'IP spécifiée dans le fichier de configuration, (192.168.1.200) configurez-la pour qu'elle réponde au ping et au ssh. Ensuite, branchez un worker configuré comme expliqué sur le réseau où elle se trouve… (en respectant la config d'IP selon le fichier de config dans Nagios bien sûr).

Et comme par magie les deux machines seront prises en charge, de par leur configuration, le worker va contacter le job server, lui signaler sa présence, et là il enverra des tâches de check au worker qui les exécutera et renverra le résultat au job server qui lui-même répondra à Nagios.

Je vous vois venir, vous pensez : « Mais comment est-ce que je vois ce qui se passe derrière tout ça ?

Eh bien il y a une solution toute faite : gearman_top !

Il se trouve dans /opt/bin/.

On peut ajouter son path dans la variable path en ajoutant :

PATH=$PATH:/opt/bin

Dans le fichier /root/.bashrc.

Comme ça, vous pourrez le lancer comme n'importe quelle commande.

Lancez-le, et admirez :

Voici une petite illustration d'une infrastructure avec 8 hostgroups, et des workers.

J'ai mis un serveur qui en gère 6 à lui seul, et 2 workers qui en gèrent un chacun.

J'ai utilisé des noms de clients donc je les ai censurés pour cet exemple.

Mod-Gearman améliore énormément les performances de Nagios !

Même si vous ne comptez utiliser ni le distributed monitoring, ni le load balancing, ou le fail over, le choix d'utiliser Mod-Gearman sur votre Nagios améliorera très nettement (on parle là de la moitié de consommation processeur, mesdames !) les performances du serveur Nagios.

Pour les cas testés, et pas uniquement par moi, les gains de performances sont pratiquement de 50 %.

Tests réalisés sur des serveurs qui ont une utilisation moyenne de 55-60 % de processeur, le fait de juste passer sur Gearman fait chuter la consommation processeur vers les 25 %.

Mod-Gearman EST un must, chers amis !

Voici une petite liste des problèmes que j'ai rencontrés en démarrant seul sans aucune info sur Mod-Gearman , le jour où j'ai décidé de me pencher sur cette technologie et d'apprendre à partir de rien à m'en servir.

10-1. Timeout sur workers▲

10-2. Compilation Gearman▲

10-3. Plantage Gearmand au lancement▲

Je conclus cette rubrique par ce point, la surveillance de vos workers.

Si vous avez bien compris le fonctionnement des workers, on peut déceler une faille…

Si un worker n'est plus accessible, comment va-t-il répondre au job server pour dire qu'il n'est pas accessible ? On est d'accord, c'est impossible. Alors, comment déterminer si un worker est OOR (out of range) ou non ?

J'ai pondu un petit script utilisant gearman_top qui permet ça. Le voici :

Le script :

#!/bin/bash 
 
basevalue=`/opt/bin/gearman_top -b | grep "hostgroup_$1-servers"` 
 
value1=`echo $basevalue | cut -d "|" -f3 | tr -d ' '` 
value2=`echo $basevalue | cut -d "|" -f4 | tr -d ' '` 
value3=`echo $basevalue | cut -d "|" -f2 | tr -d ' '` 
 
critical=$2 
threshold=$(($2/2)) 
 
if [[ $value1 -gt $critical ]] 
       then    
              if [[ $value2 -gt $threshold ]] 
              then 
                     echo " Accumulation de Jobs sur le worker $1, attention!" 
                     echo " $value1 jobs en attente , $value2 jobs en cours " 
 
                     retval=1; 
              else 
                     echo " Le worker $1 ne prend plus de Jobs, Critical! " 
                     echo " $value1 jobs en attente!" 
 
                     retval=2; 
       fi 
else 
       echo "Tout va bien. $value1 Wait $value2 run $value3 avail" 
       echo "$value1 jobs en attente, $value2 jobs en cours et $value3 workers dispo." 
retval=0; 
fi 

exit $retval;

le fichier de définition de commande :

define command{ 
       command_name    check_workers 
       command_line    /usr/lib/nagios/plugins/check_workers.sh $ARG1$ $ARG2$ 
       }

Et un exemple utilisé sur mon serveur :

define service{ 
       use                     generic-service 
       host_name               ALTAIR-SRV-NAGIOS01 
       service_description     Worker Altair 
       check_command           check_workers!altair!15 
       }

Ma société veut que les jobs en attente, en exécution et les workers prêts à traiter pour le hostgroup altair me soit rendus, et dans le script , j'exécute gearman_top avec l'option -b qui ne rend qu'une réponse, et utilisable en script, je trie avec un grep pour obtenir le nom qui m'intéresse, et ensuite je décortique les chiffres, et définis selon le nombre de jobs waiting que je veux d'avoir une alerte s'ils atteignent ce seuil, avec une petite sécurité toutefois, s'il y a une accumulation de checks pour une raison, peu importe laquelle, mais que mon worker travaille, je ne veux pas recevoir d'alerte. Je le laisse bosser…

L'équipe Réseaux tient à remercier Nicolargo pour la rédaction de ce tutoriel.

Nos remerciements à LittleWhite pour sa gabarisation et à Phanloga pour sa relecture orthographique.

N'hésitez pas à faire part de vos remarques et commentaires à propos de cet article sur le forum ! Commentez