Patch Nagios : SSL pour Ndo

Posted in Nagios by Nap on October 16, 2009 2 Comments

J’avais travaillé sur 3 patchs pour Nagios et je n’en ais évoqué ici que 2 pour la bonne raison que c’étaient les seuls à être intégrés. Et bien en fait c’est inexact : le troisième l’a été aussi :)

Ce patch permet d’établir une connexion chiffrée entre le module ndomod et ndo2db. En effet, avant tous les paquets étaient envoyés en clair sur le réseau. Ceci a beau être de la supervision, il y a tout de même le nom de toute nos machines, c’est assez embêtant. Avec le patch que j’ai proposé (commit sur http://nagios.git.sourceforge.net/git/gitweb.cgi?p=nagios/ndoutils;a=commitdiff;h=9d9dcccab9690c896a7f1c3d2015064430c5157a par Hendrik Baecker) il y a une option de plus sur ndomod.cfg et ndo2db.cfg : use_ssl.

Par défaut elle est à 0 pour un soucis de compatibilité. Une fois passée à 1, la communication sur socket (uniquement celle en réseau, pas cette sur le socket unix) est chiffrée.

Je n’ai pas réinventé la roue, j’ai emprunté le code à NRPE tout simplement. Je l’ai juste un peu adapté et mis au bon endroit.

Et voila, je suis dans le fichier THANKS de ndoutils maintenant :)

Shinken : 100K checks/5minutes

Posted in Nagios by Nap on October 13, 2009

Je viens de faire un test sur une “petite” machine : un Xeon 5140 (4coeurs, 3.1Ghz). J’ai réussi à dépasser la symbolique limite des 100000 (oui oui, 100K) checks en 5 minutes. J’ai un peu triché pour cela : j’ai exporté le broker et la base MySQL sur un autre serveur. J’arrive à un trafic à 50Ko/s entre le scheduler et le broker, ce qui est raisonnable vu le nombre de checks ;)

Petite preuve avec un ninja situé sur la machine avec la base :

100kPour ceux qui sont curieux : oui, Ninja rame un peu avec autant de services à gérer, mais cela reste acceptable ;)

Cette configuration sera de plus la plus répandue sur les gros environnements avec plusieurs schedulers. Pour rappel, sur cette même machine je plafonne à 10K checks avec un Nagios non tuné, 30K en le tunant un max.

Moi je ne dirais qu’une chose : merci Python, mettre en place un pool de process est d’une simplicité monstrueuse. Maintenant, reste à faire de même avec Nagios (et de convaincre ses auteurs…). Qui sait, la barre des 200K sera peu être atteinte un jour?

Shinken : Les grandes lignes

Posted in Nagios by Nap on October 6, 2009 2 Comments

Il y a quelques temps j’ai présenté dans les grandes lignes mon proof of concept Shinken, le Nagios en Python. Et bien il a plutôt bien avancé depuis. En voici un état des lieux et une idée de là où il va.

Architecture générale

Shinken est pensé pour les environnements distribués. Il est bien sûr possible de faire tourner tous ses composants sur une seule et même machines. Les composants justement, parlons en.

Architecture de Nagios

Nagios est (quasiment) monolithique. Il lit la conf, la traite, ordonnance les checks, les lance ainsi que les actions qui en résultent (les notifications et les event handlers). Il exporte également des informations vers un daemon externe pour mise en base de données.

Lorsque l’on a un petit environnement, tout marche bien, c’est pratique et presque rapide. Le problème se pose avec les grands environnements : Nagios est capable de gérer facilement jusqu’à 10000checks/5minutes sur un serveur moyen de gamme. Avec du tuning on peu arriver à 30000, mais gère plus, même en rajoutant pleins de CPU sur le serveur. La mise en place des environnements distribués n’est pas triviale (la preuve, elle demande un chapitre à part entière dans mon livre :) ). La tâche est encore plus hardue pour les environnements distribué ET hautement disponibles. Cette dernière exigence est très complexe à gérer si on ne veux pas perdre trop en performances, voir pas faisable du tout pour les très gros environnements sauf à mettre une armée de serveurs.

C’est là que vient Shinken : mettre en place un environnement distribué hautement disponible facilement. Le côté facile doit venir aussi de la gestion de conf. Nagios a une gestion de la configuration impressionnante, mais qui nécessite un gros travail manuel lorsqu’il est question d’environnements distribués.

De même pour donner des ordres à Nagios, il faut passer par le pipe nommé nagios.cmd situé sur le même serveur. Pour un serveur ça va, mais pour une dizaine, se souvenir sur quel serveur Nagios se trouve l’hôte que vous voulez rescheduler devient un peu plus complèxe…

Pour résumer la situation, l’architecture de Nagios est la suivante:

nagios-architecture

Architecture de Shinken

Shinken propose une solution à ces problèmes : le découplage des rôles de Nagios. Ces rôles sont éparpillés sur différents processus. Voici le schémas global, le rôle de chaque élément sera précisé plus bas:

shinken-architecture

  • Arbiter : lit la configuration, la découpe en N partie et l’envoi vers les autres processus. Il lit l’unique fichier nagios.cmd de l’architecture, et transmet les ordres à qui il faut. Il est également le garant de la haute disponibilité et la répartition de charge.
  • Schedulers (nom de processus Shinken) : il lit la conf que lui envoi Arbiter. Il peux y avoir N schedulers, chacun avec ses propres éléments (hôtes/services). Il est en charge d’ordonnancer les checks, de les proposer aux autres éléments, récupère le retour des checks, et propose des notifications/event handlers si besoin qui seront lancé par des éléments externes.
  • Pollers : Il peux y en avoir autant qu’on veut. Ils récupèrent les checks auprès des schedulers, les lance et renvoi le retour aux scheduler en question. Il n’y a pas intelligence ici. Ils récupèrent des checks, les lancent, renvoient le résultat. Point barre.
  • Actionner : De préférence il n’y en a qu’un (et un spare). Il est en charge de lancer les notifications et les event handlers. Il fonctionne de la même manière que les pollers, mais il est à part car on préfère en avoir un et un seul qui fait les notifications (pour les problèmes d’acès aux serveur SMTP ou les flux RSS par exemple).
  • Broker : Unique avec un spare, Les schedulers exportent des informations dans des ‘broks’, des morceaux d’informations. Ils sont récupérés par le Broker qui en fait ce qu’il veut après, suivant les plugins qu’il a. Chaque plugin traite l’information comme il le veut. Les plugins actuellement développés sont l’export du fichier service-perfdata et l’export dans la base merlin. La base ndo ne devrait pas tarder, mais ca sera plus long que pour celle de merlin, car elle est vraiment mal fichue!
  • Bah c’est tout. C’est déjà pas mal non? :)

Les éléments de charge sont éclatés d’où le load balancing. L’arbiter est le garant de la haute dispo, il réparti les conf aux vivants, et envoi les conf des éléments morts aux spare si un membre actif vient à mourrir (bah ca peut arriver hein, personne n’est parfait). L’administrateur n’a pas à se soucier de quel scheduler va gérer son élément (hôte), l’arbiter va découper la conf pour lui de manière automatique, et en faire des paquets les plus équilibrés possible en terme de charge. Shinken tiens son nom de là d’ailleurs :)

La configuration

Qui dit nouveaux éléments dit nouvelle configuration. L’arbiter mis à part, chaque élément a un élément de configuration qui lui est dédié. Elle est de la forme (par exemple ici pour les scheduler):

define scheduler{

name     scheduler-main

address      192.168.0.1

port      7768

spare        0

}

define poller{

name      poller-main

schedulers     scheduler-main, scheduler-spare

address      192.168.0.1

port      7771

}

Ceci doit être donné à l’arbiter dans le fichier nagios.cfg, comme n’importe quel autre configuration d’éléments dans Nagios. Ceci va permettre à l’Arbiter d’envoyer les configuration et de gérer les liens avec les schedulers, pollers and co. Je n’ai pas encore prévu de configuration locale au poller and co. Mais à part le port d’ouverture, il n’y aura pas gand chose à configurer.

Je prévois de faire en sorte de créer automatiquement un élément en local s’il n’est pas défini dans la configuration, genre dans le cas de l’import d’une configuration existante sans avoir à la modifier.

Les performances

J’en vois déja arriver avec leur grands sabots : “c’est en python donc c’est tellement lent qu’on ne va pas pouvoir tester sur de vrais environnements”. Ca aurait été sacrément inutile si c’était le cas. Je n’aime pas trop perdre mon temps. Allons directement à la mesure dans de vraies conditions : serveur Xeon bi-coeurs 3ghz. J’ai utilisé une configuration générée tout comme dans le chapitre 9 de mon livre (quoi,vous ne l’avez pas encore lu?). La latence nous permet de savoir si le programme a assez de ressources ou non.

  • Nagios dans sa configuration standard a stagnée a 9500 checks/5min, avec du tunning poussé, 25000. Je n’ai pas encore fait les tests avec export en base de données avec ndo2db;
  • Shinken arrive à 50000 avant que j’ai eu à faire du tunning de code…Et l’export en base de données fait en prime, le tout sur la même machine bien sûr.

Il n’y a pas de secret ici : La charge de Nagios vient du lancement de nouveaux process Nagios qui doivent lancer les plugins et le fait de “reaper” les résultats dans des fichiers plats. Shinken utilise un pool de process (les pollers ont un pool de workers) donc pas de surcharge ici, et les pollers envoient directement les résultats des checks en mémoire (technique d’objets distribués de type Corba, mais en autrement plus simple à utiliser). Pas de fichiers à parser, beaucoup moins de charge. “Et voila”.

Par contre ce n’est pas parfait : le lancement de l’Arbiter est légèrement plus lent que Nagios pour la lecture de la configuration, mais rien de rédhibitoire. Je vois revenir les gros sabots pour la consommation mémoire : Oui, ceci consomme plus de RAM que Nagios. Nagios est vraiment bien optimisé sur ce point, Shinken est “seulement” 3 fois plus consommateur, genre 250Mo pour les 50000 checks. C’est tout à fait acceptable à mon goût.

Bref, c’est testable même avec des grands environnements. Et ca veut dire que l’on peut encore améliorer Nagios. Bon reste à faire la partie Worker en C. Je l’aurais bien prise chez Apache, mais question de licence, ça le fait pas je pense. Puis le code est .. complexe pour juste une gestion de worker, mais bon c’est le C hein…

Ce qui est déjà fait

Les fonctionnalités principales de Nagios sont déjà dans Shinken:

  • ordonnancement de Nagios (HARD, SOFT, etc)
  • gestion des périodes de temps Nagios (sauf les exclusions)
  • checks passif
  • gestion des dépendances
  • macros
  • vérification de la fraicheur des états
  • export des données de performances
  • export des données dans une base MySQL de type Merlin
  • la gestion du flapping
  • le cache de checks pour les dépendances
  • services volatiles (pour les logs)
  • gestion du fichier de rétention

Pas si mal hein?

Ce qu’il reste à faire

Avant de le présenter “officiellement” aux auteurs de Nagios, je tiens à ce que la gestion des spares soient complète. De même que l’export vers la base ndo. Après je le présente, avec dans l’espoir de voir les bonnes idées s’il y en a (comme le pool de process) intégrée dans Nagios si c’est possible. (Bon tout est possible, mais en C ça devient beaucoup plus long à faire… beaucoup plus long à faire même…et pourtant j’aime le C, faut pas croire).

Ah oui, il faut que je fasse une VM de type VirtualBox avec Shiken et Ninja pour l’interface. En fait plusieurs VM seraient mieux pour l’aspect distribué.

Sortie de mon livre sur Nagios

Posted in Nagios by Nap on August 26, 2009

En octobre dernier j’ai entreprit d’écrire un livre sur Nagios. Après avoir écris plusieurs articles sur le sujet dans Linux Mag, il était temps de se lancer un nouveau défi. Je dois bien avouer que je suis particulièrement fier du résultat. Il est édité par Eyrolles dans la collection blanche. Ca tombe bien, c’est ma collection favorite (il n’y a qu’a regarder ma bibliothèque). Voici une petit photo de la couverture :

nagios3

Je n’ai pas été seul à travailler sur cet ouvrage. Je remercie encore chaleureusement ma femme Caroline pour ses diagrammes (je ne suis pas doué avec open office draw, elle oui :) ) et également Cedric Temple pour sa préface que j’apprécie énormément.

Le livre est découpé en trois grande partie:

L’aprentissage de la supervision/métrologie avec la théorie (et oui, il faut y passer!) et une première mise en place de Nagios.

Les techniques avancées de Nagios pour gérer les cas particuliers comme les Trap SNMP mais le tuning de Nagios ou la mise en place d’environnements distribués hautement disponibles.

Enfin, la dernière partie concerne l’écosystème de Nagios avec des outils indispensables comme Centreon ou Nagvis.

Ce livre a un but simple : faire le tour de la question Nagios. Une fois qu’un administrateur l’aura lu, il connaitra tous les principes et les astuces qui entourent Nagios et ses principaux outils (Centreon et NagVis). Il sera de même à gérer du début à la fin un projet de supervision/métrologie. En effet, l’accent est tout particulièrement mis sur l’aspect humain d’une telle entreprise. Faire accepter un util de supervision n’est pas aisé, même avec la meilleure volonté du monde. Ce livre donne toutes les informations pour déminer le terrain et permettre d’avoir un système informatique le plus efficace qu’il soit.

Au passage, c’est l’écriture de ce livre qui m’a permis de voir les plus gros points noirs de Nagios (oui, il en a quelques uns et je n’évite pas d’en parler dans le livre) et de les corriger. Par exemple, sans le chapitre 8 sur la gestion de configuration pour les grands environnements, le patch pour qu’un service appliqué sur un hôte passe devant le même service apliqué sur un groupe d’hôtes ne serait pas être jamais sorti ;)

Je continue bien sûr mon activité dans le monde Nagios avec comme point de mire les performances et les environnements distribués pour avoir un Nagios encore plus fort dans le monde de l’open source, et même au delà.

Patch Nagios pour une gestion plus fine de la configuration

Posted in Nagios by Nap on July 2, 2009

Lorsque l’on étudie un peu la gestion de configuration de Nagios, on est impressionné  par la richesses des possibilité, que ce soit sur les macros, les services appliqués sur les groupes, les exeptions, etc. En fait, une seule fonctionalité manque lorsque l’on souhaite gérer finement et effiacement sa configuration : les exeptions sur les services appliqués sur des groupes de noeuds.

Un tel service appliqué sur un groupe prenait systématiquement le pas sur le même service appliqué sur un noeud. On était obligé de contourner le problème avec la mise en place de MACROS spécifiques et de modifier les commandes. Ce n’est désormais plus nécessaire avec la nouvelle version de Nagios. J’ai proposé dernièrement un patch qui a été appliqué dans la 3.1.2.

Cette modification permet à un service appliqué sur un noeud de prendre le pas sur le service appliqué d’un groupe. Cette possibilité permet de définir très simplement une execptions d’un service, sans avoir à sortir un noeud d’un groupe et dupliquer tous les autres services qui y étaient acrochés.

Par exemple, avec la défiition suivante :

define service{
use     generic-service
hostgroup_name       all-server
service_description     service-test
check_command   check_ping
}

define service{
use     generic-s
ervice
host_name       srv-1
service_description     service-test
check_command   check_local_disk
}

Et bien maintenant c’est la seconde définition qui va gagner, ce qui est tout de même bien pratique :mrgreen:

Shinken : quand un python rencontre Nagios

Posted in Nagios by Nap on July 2, 2009

J’ai commencé voila quelques temps le projet Shinken. C’est une ré-implémentation de Nagios en Python qui va me permettre de maqueter certains principes pour Nagios avant de me les fader en C. C’est pour cela que j’ai choisi le langage Python qui est particulièrement élégant et jouissif. Si vous ne le connaissez pas, aller faire un petit tour sur http://www.python.org/ et laissez vous emporter par ce super langage.

Shinken est le résultat de mon étude de Nagios dont je parlerai un peu plus tard. Ce projet est déjà très efficace, mais j’étais persuadé que certains petits détails étaient encore améliorables. Par exemple, le lancement des sondes est ce qui coute le plus cher en terme de performance pour Nagios. Éviter de forker en ayant un pool de processus peut être bien plus intéressant. Ceci se code en quelques lignes de Python. De même, les aspects distribué de Nagios ne sont pas parfait. Les Nagios n’ont aucune connaissance des autres. Si avec des solutions comme Centreon il est facile de les gérer, certains problèmes persistent comme les notifications qui sont envoyées par chaque Nagios et ce séquentiellement.

L’intérêt de Shinken est de reprendre la configuration de Nagios ainsi que ses principes de supervision qui sont très pousés tout en proposant une novuelle architecture pour le programme à proprement parlé. Shinken est par exemple capable de couper automatiquement la configuration en partie totalement indépendantes qui vont pouvoir être, encore automatiquement, envoyées vers un scheduler qui va ordonnancer les vérifications et prendre les décisions en cas de problèmes.

Le nom du projet n’a pas été facile à trouver : je suis très long pour trouver des noms. Je peux dire merci à Wikipedia pour celui-là. je cherchai un nom de sabre japonais (j’aime bien la sonorité des noms japonais) et je suis tombé sur celui-là. Le sabre illustre la faculté de couper la charge automatiquement sur plusieurs machines. Et le Shinken est le sabre qui coupe le plus.

Le code est déjà bien avancé et est en licence AGPLv3.  Je reviendrai plus tard sur ce choix. Je suis en train de monter une première version sur sourceforge. Et plus important encore, le logo est déjà prêt :)

shinken

Merci à l’auteur cisoun pour sa mascotte ouaaargh qui a servi de base à ce logo :)

Pour ceux qui veulent voir un peu ce que cela donne, vous pouvez obtenir la dernière version du code avec git (paquet git-core sous debian):

git clone git://shinken.git.sourceforge.net/gitroot/shinken/shinken

Patch Nagios pour un démarrage (bien plus) rapide

Posted in Nagios by Nap on July 2, 2009

Il y a de cela un an, j’ai pris au mot l’auteur de Nagios lorsqu’il écrit dans la documentation de Nagios concernant les vérifications effectuées au démarrage :
“That means all you CompSci graduate students who have been emailing me about doing your thesis on Nagios can contribute some code back. :-)
Je ne sais pas qui ils sont, mais j’ai essayé de résoudre le problème poser : la vérification des liens de parentés dans Nagios était horriblement longue. En fait, j’ai même réussi.

Pour rappel, Nagios permet de définir pour un host un ou plusieurs parents (en terme de réseau). De cette manière, si un switch tombe par exemple et que l’administrateur a bien configuré ses serveurs pour qu’ils soient des fils du switch en question, il ne va recevoir qu’une seule alerte, celle du switch, plutôt que N alertes des serveurs. C’est la dépendance réseau. Cette relation forme un arbre : Nagios remonte les branches pour trouver la cause du problème. La racine est le noeud Nagios lui même. Mais que se passe-t-il si on autorise les cycles dans la configuration? Nagios va tourner en rond lors de la recherche de l’erreur! :evil:

Pour éviter cela, Nagios fait une vérification au démarrage afin de trouve les cycles dans cette configuration s’ils existent. Un premier algorithme naïf est en O(n²). Et bien dans Nagios arrivait à faire du O(n3)… Vous aller me dire que ce n’est pas si grave que ça. Et bien en fait si. Prenons une configuration “costaux” de 40000 hosts avec des relations de parentées. Et bien la vérification prends 70s sur un Core2 à 2.4Ghz. Ce n’est pas négligeable, car pendant ce temps, il n’y a pas de supervision…

J’ai donc décidé d’appliquer mes cours de théorie des graphes et de faire un simple parcours en profondeur, aussi nommé Deep First Search (DFS). C’est donc un algorithme récursif, ce qui n’a rien d’étonnant dans le monde des graphs :mrgreen:

Son fonctionnement est légèrement différent du DFS standard, car le but n’était pas de savoir si une boucle existait, mais de trouver TOUS les noeuds étant dans une boucle, afin d’aider l’utilisateur à corriger les problèmes en un passage.De plus, il n’y a pas de noeud root sur cet arbre de relation. On peut potentiellement partir en plein milieu de l’arbre, ce qui ne facilite pas les choses.

Les noeuds peuvent avoir plusieurs attributs :

DFS_UNCHECKED 0 valeur par défaut
DFS_TEMPORARY_CHECKED 1 a été parcouru une fois
DFS_OK 2 pas de problème
DFS_NEAR_LOOP 3 a des fils à problèmes
DFS_LOOP_INSIDE 4 fait parti d’une boucle

Nouveau test avec ce parcours en profondeur au lieu de l’algorithme initial : 0.006864 sec :-D

Après une longue période de non réponse de l’auteur de Nagios et le “coup de pied au cul” de Icinga avec leur tentative de Fork, de nouveaux développeurs ayant accès au CVS de Nagios ont été nommés. C’est ainsi que mon patch a été intégré dans la version 3.1.2 de Nagios et que des milliers d’administrateurs vont voir leur Nagios démarrer bien plus rapidement.

Reste à appliquer ce principes aux autres relations de dépendances dans Nagios…

« Previous Page