Distributed Monitoring Nagios à l’aide de Mod-Gearman

Date: 4/09/2013 | Catégories: Open-source,Planet-libre,Reseau,Systeme | Tags: ,,

Pour nous parler de Nagios et de supervision distribuée, j'ai le plaisir d’accueillir sur ce blog, en tant que rédacteur invité, Laurent Hugot. Laurent travaille actuellement pour la société Altair en Belgique et à en charge les activités de supervision.

===

Le "Distributed Monitoring" est une solution utilisée lorsque l’on veut surveiller plusieurs sites avec une seule installation de Nagios, qu’elle soit redondante ou non. La solution mise en avant dans ce billet est Mod-Gearman qui est un module Nagios abouti, performant et fiable.

Que nécessite cette solution ?

Le DistributedMonitoring 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

Comment cela fonctionne-t-il ?

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:

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

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

Côté technique

Le serveur de Jobs ne contacte pas les workers. Ce sont les workers qui contactent le serveur de jobs.

Cela implique qu’il soit joignable depuis l’extérieur, mais cela implique surtout que vos workers , à l’abris derrière des firewalls bien configurés, pourront communiquer sans le moindre souci avec votre serveur de jobs. Cela vous épargne de devoir percer le moindre trou dans les Firewalls de vos précieux clients.

Les connexions entre vos workers et votre (ou vos) job server(s) sont chiffrées, vous pouvez configurer votre structure pour désactiver ce chiffrement, si vous le souhaitez. On peut configurer la structure pour gérer les hosts et les services ou alors gérer les hostgroups. Ici j’aborderai la solution Hostgroups, pour le distributed monitoring, le mode host&services serait plutôt du failOver et loadbalancing pur.

Côté pratique

Pour faire simple (mais alors vraiment simple): on installe le serveur jobs sur le serveur de Nagios, on configure le NEB (Nagios Event Broker) dans la configuration de Nagios, et ensuite on configure un worker par site à surveiller, on le branche et c’est terminé. (Oui, aussi simple.)

Plus sérieusement : la configuration sera expliquée plus bas, mais le système est fait de telle façon à accueillir chaque worker qui se connecte au serveur de jobs, et de cette façon la distribution est totalement automatique tant que la configuration des hostgroups et du worker est faite comme il se doit.

Un peu de théorie

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:

nagios-modgearman

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 , et un fichier par machine , et un dernier fichier comprennant les personnes de contact à mailer pour les alertes, et les plages horaires.

Le reste des fichiers de configuration sont 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 qui lui restitue les résultats.

Il n’y a pas de modifications à apporter à Nagios pour 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.

Préparatifs et installation étape par étape

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é pour Debian, travaillant exclusivement sur cet OS. Merci Antoine Habran 😀 )

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

En bonus car on peut s’en passer, car 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 ? 

Explications

Nous allons télécharger et installer sur notre serveur Nagios « Gearmand »  qui est le « moteur » de mod-gearman , et ensuite, mod-gearman. La seconde étape consiste à configurer Nagios en mode Broker et à configurer le job server. Ensuite, on passera à la création d’un hôte d’exemple pour expliquer comment il sera géré et que vous puissiez vous en inspirer. Pour terminer on configurera un Worker (je ferai un exemple d’un worker Raspberry Pi Mod.B et un worker sur un debian 7 normal sur VM machine physique)

Installation de Mod-Gearman

Ah ouais, là on y est ! les prochaines lignes vont décrire les étapes nécessaires a l’installation de mod-gearman , et on va procéder comme suit :

  1. Installation des packages pour l’installation
  2. Téléchargement de la source de Gearmand
  3. Décompression de la source Gearmand
  4. Compilation de Gearmand
  5. Installation de Gearmand
  6. Téléchargement de la source de mod-gearman
  7. Décompression de la source mod-gearman
  8. Compilation de mod-gearman
  9. Installation de mod-gearman
  10. Configuration du job server mod-gearman
  11. Configuration du N.E.B de Nagios
  12. Configuration du Worker mod-gearman

Là nous aurons un serveur mod-gearman complet et opérationnel.

Il ne manquera qu’un Worker pour surveiller un site distant, mais le serveur sera fonctionnel et autonome, déjà.

D’abord avant de faire quoi que ce soit, il faut installer tous les prérequis pour la compilation et l’installation de gearmand, et mod-gearman.

Donc , si vous avez bien mis à jour votre système (apt-get update , apt-get upgrade)

On lance ceci :

On devrait avoir à ce stade tous les éléments pour la compilation, sauf un (libgearman6) qui doit s’installer après.

On passe ensuite au téléchargement et décompression des sources de Mod-Gearman:

Maintenant on prépare le système pour réaliser l’installation de gearmand dans le dossier /opt/ en faisant comme ça , on peut le mettre à jour très facilement et proprement , ou le supprimer. Tapons ces deux lignes :

On lance l'installation:

Et si jusqu’ici tout a bien fonctionné et que vous n’avez pas d’erreurs : Le plus dur est fait !.

Maintenant que Gearmand est installé, on peut installer Mod-Gearman.

Puis on lance l'installation:

On doit maintenant copier un fichier vers /etc/init.d pour pouvoir lancer proprement gearmand.

ensuite il faut ajouter un shell a l’utilisateur Nagios 

Voila qui est fait.

Note: Correction du script de démarrage de Gearmand 

Si vous subissez un plantage lorsque vous tentez de démarrer gearmand , (ce qui était systématiquement mon cas…)  il y a une modification à faire dans le script de démarrage /etc/init.d/gearmand

Démarrez gearmand :

Si vous avez un crash, c’est quasi obligatoirement ceci : La ligne 89 du script contient un argument de verbosité qui fait planter gearmand.

Supprimez l’argument de verbosité dans cette ligne :

CMD="$DAEMON -p $PORT -P $PIDFILE $OPTIONS --log-file=$LOGFILE --verbose=2 --listen=$LISTEN"

Et retirez le --verbose=2

Cette option, pour une raison qui m’échappe fait planter gearmand.

Si tout fonctionne, arrêtez Gearmand (On le rallumera plus tard).

Configuration du Job Server sur le serveur

Configurons le serveur de jobs pour l’intégrer à nagios et le rendre prêt à accueuillir un worker.

Éditons le fichier de config /opt/etc/mod_gearman_neb.conf:

Ici l’important, c’est la key, elle doit être identique sur votre fichier NEB et sur vos workers.

La « queue_custom_variable » est essentielle aussi, elle définit ce qui qualifie un worker pour la configuration d’un hôte. Vous verrez pourquoi on définit cette valeur plus loin.

On va passer au worker maintenant.

Configuration du Worker sur le serveur

On va configurer notre serveur pour qu’il surveille le site dans lequel il se trouve. En faisant cela, notre serveur Nagios – mod-Gearmand va surveiller le hostgroup dans lequel vous avez mis toutes vos machines, un peu comme avant l’installation de mod-gearman.

Pour ça , on édite le fichier /opt/etc/mod_gearman_worker.conf (avec quelques informations masquées... je conserve un peu de secret concernant mon infrastructure de production :D):

Voila, c’est une configuration basique, pour le worker du serveur. Ajoutez les hostgroups que vous souhaitez checker avec CE worker , le mot de passe partagé par le serveur et les workers, et l’ip du serveur. Le reste sert à gérer le comportement du worker, ses limites, seuils.

A partir de là , le système est prêt à fonctionner, mais… pas la configuration de Nagios. On va donc s’occuper de ça !

Configuration de Nagios

Nous devons éditer Nagios pour lui dire que maintenant c’est papa qui s’occupe des checks.

ATTENTION : Ne JAMAIS inclure ou retirer de module BROKER (comme on va faire là) a chaud, ne jamais modifier quelque fichier que ce soit d’un module BROKER a chaud.

Distinction entre fichiers de module et fichier de config de mod-gearman toutefois.

Mod-gearman est indépendant du module broker et peut être redémarrer pendant que nagios tourne. Pour l’inclusion du Broker dans nagios, on arrête celui-ci.

On va éditer son fichier de configuration /etc/nagios3/nagios.cfg

Note: En une ligne séparé d’un espace.

Configuration des hostgroups

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 :

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

il nous faut un worker sur le site distant, disons que le client2 est a 200Km d’où je me trouve, je me rend 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 

Voici le fichier contenu de mon fichier hostgroup1.cfg:

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

Voila 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 :

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

et le fichier de config du worker

Configuration du worker présent sur le serveur

Alez sur votre serveur éditer le fichier de config /opt/etc/mod_gearman_worker.conf et modifiez pour que la ligne:

soit :

Démarrage de l’infrastructure

D’abord, on va démarrer Nagios,  gearmand, ensuite le worker mod-gearman.

Et ensuite :

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

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

Note: AVANT la ligne “exit 0” (sinon ça ne fonctionnera pas)

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 :

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

Worker Raspberry Pi Mod. B

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 :

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

Ouais… C’est tout!

Par défaut il va gérer le worker comme un petit chef, rien besoin 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 check, si vous avez par ex. un check qui met 2Mn à 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 vita aeternam le résultat , et sera par conséquent… Planté ! ça ne vous ferait pas plaisir de faire 200Km 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 config, (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 ou 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 part 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 éxécutera et renverra le résultat au job server qui lui-même répondra à Nagios.

Surveillance des jobs

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

Et 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 :

Dans le fichier /root/.bashrc

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

Lancez le , et admirez :

capture_115

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.

Performances

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

Même si vous ne comptez ni utiliser 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, mesdammes !) les performances du serveur Nagios.

Pour les cas testés, et pas uniquement par moi, les gains de performances sont de pratiquement 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 !

Problèmes rencontrés

Voici une petite liste des problèmes que j’ai rencontré en démarrant seul sans aucune info sur mod-gearman , le jour ou j’ai décidé de me pencher sur cette technologie et d’apprendre a partir de rien à m’en servir.

Timeout sur workers :

Au début je n’avais pas défini de temps de timeout sur les workers… ça m’a vallu un déplacement aussi long qu’inutile pour aller reboot le raspberry pi, n’oubliez pas de définir le job_timeout= sur vos workers…

Compilation gearman :

En temps normal je me contente de faire apt-get install lorsque j’ai besoin de quelque chose.

Or quand j’ai commencé à me servir de mod-gearman, les packages n’étaient pas disponibles en repo pour l’apt-get install… donc j’ai du me mettre à le compiler moi-même , d’où la procédure ou on voit sa compilation alors que des versions (évidemment pas aussi à jour que celle expliquée ici, au jour ou j’écris ceci) sont disponible en repo…

Je n’ai certainement pas réalisé le sans fautes, probable que certains packages dans la phase d’installation des paquets ne sont pas essentiels, mais j’ai trié au maximum et je pense avoir fait ça proprement. Je suis preneur pour toute suggestion ou remarque 

Plantage gearmand au lancement :

Comme je le décris dans la procédure, il y a un plantage qui peut survenir au lancement de gearmand , qui se corrige par une modification du fichier dans /etc/init.d , ce problème m’a fait perdre pas loin d’une semaine, en ayant retourné le problème dans TOUS les sens , j’étais loin de suspecter qu’une option de verbosité, normalement présente pour aider a la résolution de problèmes de pantages, soit la cause du problème que je traquais… Comme quoi, il faut se méfier de tout.

Surveillance des workers

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:

le fichier de definition de commande:

Et un exemple utilisé sur mon serveur :

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’éxé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...

  • Cela apporte quoi par rapport à une configuration nsca classique ? (qui semble bien plus simple à mettre en place).

    • Interessant cet article. par contre je me pose la meme question, effectivement :p
      D’un autre coté, si on a un réseau firewallé dans tous les sens, cela permet d’autoriser juste une connection entre le worker et le server nagios, plutot que n autorisations entre le nagios et les machines à surveiller.

      • Avec nsca c’est aussi possible.
        Des serveurs intermédiaires qui monitorent un petit groupe de serveurs via nrpe et font remonter à un master via nsca. On peut mettre des règles simples pour gérer ça au niveau du firewall.

  • lkco

    J’utilise mod_gearman en production avec beaucoup de réseaux segmentés. C’est une tuerie…
    J’ai fait des benckmarch : 500 hosts and 5000 services, check tous les minutes avec des plugin qui génèrent volontairement de la latence. Résultat, une latence quasi divisé par 2 :
    http://www.fullyautomatednagios.org/wordpress/wp-content/uploads/2013/06/latency.png

  • Laurent Hugot

    Comme Lkco le spécifie ,
    Mod-gearman fournit un travail efficace et surtout une diminution énorme de la charge.
    il est vraiment envisageable avec une structure de ce genre de faire tenir plusieurs milliers d’hôtes a raison de 10 services par hôte en utilisant le nombre adéquat de workers.

    accessoirement, et là je parle pour moi, je n’impose pas mon avis:
    Il est de bon ton de pouvoir éviter de percer des petits trous dans nos firewalls chéris lorsque l’on peut l’éviter.

    Donc plutôt que de travailler sur les firewalls, j’aime nettement plus l’idée que les workers établissent les connexions depuis l’intérieur des réseaux, et ça économise beaucoup de boulot, immaginez si vous avez 50 sites à gérer… 50 firewalls à percer…
    Mod-gearman vaut vraiment le détour 🙂

  • Matt

    J’essai de mettre en place un worker sur un site distance. En suivant la procédure, j’obtiens l’erreur suivante: configuration file /etc/mod-gearman/worker.conf not present. Je ne vois pas trop quoi faire et j’aimerais vraiment tester cette solution. Faut-il reprendre l’installation complète de mod-gearman ?

  • Davy

    Si jamais, je suis tombé par hasard sur un script, fournit par l’install de gearman, « /opt/bin/check_gearman » qui semble faire la même chose que ton script bash, les perfdata en plus.

    Exemple de sortie :

    check_gearman OK – 0 jobs running and 0 jobs waiting. Version: 1.1.12|’hostgroup_test_gearman_waiting’=0;10;100;0 ‘hostgroup_test_gearman_running’=0 ‘hostgroup_salanitro_gearman_worker’=1;25;50;0

  • JO The Legend

    Bonjour, savez vous si on peut mettre un « delay » de connection du worker au serveur ?? genre le worker ce connecte toutes les minutes au serveur de JOB

  • Laurent Hugot

    @JO The Legend:disqus
    Bonjour,
    je ne sais pas s’il est possible d’introduire un délai de connexion
    entre un worker et le serveur Gearmand, j’admets que je n’ai jamais eu
    un tel besoin et donc jamais cherché à le réaliser…

    @Davy:disqus

    J’ai
    découvert cela par après effectivement, cela étant j’étais pris par le
    temps car j’ai du réaliser le projet en un mois de zéro au résultat
    fonctionnel et j’ai donc opté pour une écriture des outils dont j’avais
    besoin plutôt qu’une recherche, sachant ce que j’avais besoin de faire.
    Du coup, oui le script inclus dans Gearmand est plus intéressant 🙂

  • Laurent Hugot

    PS: un bête Cronjob qui active le service pour un temps défini devrait faire l’affaire :p