Hot periods

Posted in Shinken by Nap on December 14, 2009

Ce post fait suite à celui des modulateurs de code retour. Pour rappel, ils permettent pour des services de modifier les codes retours suivants ce que l’on veut. Les deux proposés sont:

  • inverse_ok_critical : pour les services actifs/passifs
  • critical_is_warning : pour les services sur des machines de priorités plus faibles comme celles de QUALIFICATION.

Pour les machines de Qualif, nous avons aussi le cas de machines de production faible : ce n’est pas de la production 70% du temps, mais critique les 30% restant. On peut mettre un critical_is_warning pour ne pas être pollué visuellement en rouge pendant une période de faible activité, mais on perd l’avantage de la visibilité en période chaude.

Personne ne voit où je veux en venir? Et bien oui, ces périodes chaudes justement :)

Déjà tout comme critical_is_warning est settable sur un host et héritable implicitement sur les services, cette période chaude est portée par l’hôte, et si l’administrateur le veut, est settable sur le service tout de même. Cette période chaude dé-inhibe le critical_is_warning : pendant la période chaude, on repasse sur un comportement normal, avec “critical is critical”.

Un exemple? Et bien imaginez une application de paye, c’est critique 1semaine par mois (mais alors HAUTEMENT critique hein), le reste ça mérite un warning (sauf sécurité, mais là on ne met pas critical_is_warning…). Et hop, encore du rouge qui disparait sur l’interface :mrgreen:

La propriété utilisée? hot_period (sur host et/ou service si vous avez bien suivi).

Bon reste à coder cela, mais ça ne va pas être très long, mais déjà je vire la dépendance à python-graph-core… (et hop, retour dans le monde merveilleux des graphs orienté et des parcours en profondeur).

Mes premiers patchs !

Posted in Shinken by Nap on December 10, 2009

Je viens de recevoir mes premiers patchs pour Shinken. Ca fait quelque chose :oops:

C’est Gerhard Lausser qui me les a proposés. Patchs très bien écrit et permettant d’implémenter la directive cfg_dir ainsi que les trailing \ (permet d’avoir une ligne de conf sur plusieurs lignes) dans les fichiers de conf. Merci beaucoup à lui !

Shinken : des modulateurs de résultats

Posted in Nagios by Nap on December 9, 2009

Je viens de rajouter dans Shinken deux options qui peuvent se révérer intéressantes : critical_is_warning et inverse_ok_critical. Les deux options sont utiles pour remplacer des sur-chouches de checks comme negate ou nocritical.sh.

Le cas des serveurs de Qualifications

L’option critical_is_warning est utile pour les serveurs de Qualification. Il est en effet coutume d’avoir du rouge dans l’interface de supervision (et donc CRITICAL) si et seulement si c’est important et que cela demande une intervention immédiate. Mais que faire si le service remonte un état CRITICAL sur une machine de Qualification? Si deux erreurs arrivent sur l’interface, une sur un serveur de PROD, l’autre sur un serveur de Qualif, il va falloir regarder qui traiter en premier, et surtout connaître si les serveurs sont en Prod ou non. Pour les petits environnements point de problème, pour les plus gros, c’est plus difficile…

C’est pour cette raison qu’il peut être pratique de “déclasser” les résultats d’un service sur un serveur de Qualification de Critical en Warning. Un script comme nocritical.sh (si exit_code==2 ->exit_code=1) peut être utile. Le problème est que l’on devait avoir des check_command dédiées pour cela. La moindre modification était double (version avec et sans nocritical.sh).

Avec critical_is_warning, l’administrateur va pouvoir tagguer une machine comme étant non critique. Ce paramètre sera hérité par les services (héritage implicite) si le service ne le défini pas déjà. Ainsi, il est possible d’avoir pour la plupart des services ce paramètre d’absent (et donc hérité de l’hôte, 0 par défaut) et certains services critiques partout (comme ceux concernant la sécurité) avec critical_is_warning à 0. Les hôte taggué critical_is_warning à 1 seront automatiquement, et avec les même services que les autres, limités au niveau Warning. sur une configuration comme la mienne, ceci divise tout simplement le nombre de service par deux, ce qui n’est pas négligeable :)

Les services clusters passifs

Une autre problématique classique concerne les service sur les services passifs de cluster. Ils ont besoin d’être l’inverse de l’actif. Ici il n’est pas possible d’imaginer un attribut sur l’hôte, car il est cluster pour un service, mais pas pour tous les autres de l’hôte (comme le CPU par exemple). Le paramètre inverse_ok_critical fait donc le même rôle que la célèbre sonde negate (code retours : 0->2, 2->0). Il s’applique sur un service. Il va permettre de ne plus avoir de duplication des check_command, mais ne règle pas le besoin de définition d’un nouveau service. Il n’est pas dit que ce paramètre soit la solution ultime à ce problème des clusters, mais c’est une première réponse à cette problématique.

Byebye negate, tu nous auras bien aidé.

Ordre d’application

Il peut y avoir un service taggué avec ces deux paramètres. Quid alors d’un résultat CRITICAL? Et bien c’est le critical_is_warning qui l’emporte. Mais il faut être un peu tordu pour mettre les deux à vrai dire…

Shinken : quel avenir pour Nagios? Shinken?

Posted in Nagios by Nap on December 9, 2009 5 Comments

Certains ont du le remarquer : j’ai fait une proposition étonnante sur la mailing list de Nagios devel. Je ne propose rien de moins que de mettre Shinken comme branche développement de Nagios4 au lieu de l’ancienne implémentation C. Regardons un peu pourquoi je propose cela.

L’histoire récente de Nagios

Shinken est parti comme un proof of concept que j’utilisais pour démontre que mes idées pour Nagios n’étaient pas complètement absurdes. En effet, les patchs que j’ai proposés ont tous eu du mal à intégrer le core. Pourtant je les ait bien expliqué (enfin je crois), documenté et codé. Il est très simple de faire accepter un patch de correction dans Nagios, mais un patch d’amélioration de fonctionnement est bien plus long a intégrer. Pourquoi? Maitriser le cœur de Nagios n’est pas chose aisée, et je suis loin de connaître toutes ses subtilités malgré le temps que j’ai passé à le lire.

Jusqu’il y a quelques mois, Ethan était seul à accepter les patchs pour Nagios. Mes patchs ont étés magnifiquement ignorés à cette époque. Puis il y a eu l’histoire Icinga. Là Ethan a eu chaud, mais a bien réagit : il a ouvert l’accès au CVS à d’autres dev. Et hop, pleins de patchs on étés intégrés, dont les miens. Il y a eu aussi une ouverture de nagios ideas et cie. Très bien.

Et depuis? Bah Ethan se fait toujours aussi absent de la mailing list. Et qu’est ce qu’il nous sort? Nagios XI. C’est quoi cette bête? Et bien tout simplement une jolie couche graphique pour Nagios. Quel est l’intérêt face à des solutions comme Ninja ou même Centreon? Aucun. Un désavantage? C’est payant (quel bonheur de gérer des licences..) et non libre!!

Un Nagios a deux vitesses

On ne peux pas trop lui jeter la pierre, Ethan doit faire vivre sa société, et s’il décide de faire plus que du conseil/intégration et de vendre ses licenses on n’a pas à s’y opposer après tout, c’est son choix. Mais celui-ci implique que des parties des améliorations de Nagios ne seront plus open source. Il est prévu un module pour la supervision distribué… dans XI, pas dans le core. On voit poindre à l’horizon un Nagios a deux vitesses:

  • Nagios community : le Nagios open source que l’on a sous la main
  • Nagios Enterprise : le Nagios d’Ethan avec pleins de trucs géniaux, mais en close source et sous licence.

Bien d’autres font ça, Zenoss par exemple. Personnellement je ne suis pas un grand fan de ce modèle. Je n’aime pas gérer les licences, ça tombe toujours au mauvais moment ces trucs là. Je ne parle même pas de la communauté Nagios qui va fondre comme neige au soleil (vers Zabbix peut être?). Ce n’est pas acceptable.

Une stagnation dangereuse pour Nagios et une solution

Il faut un Nagios full open source qui évolue plus vite. Zenoss avance vite, Zabbix aussi, Nagios doit faire au moins aussi bien. Bien sûr il ne faut pas casser la compatibilité pour les users, c’est à dire la configuration. Mais le reste? L’administrateur s’en fiche bien que ce soit une implémentation ou une autre le temps que ça marche pareil (voir mieux…).

Les core dev ne sont pas fans des grands changement (purement technique) au sein du core. Leur réponse à un changement comme avoir un pool de process n’est pas ” c’est totalement débile comme idée”, mais “ça change trop de choses”. On peut alors légitimement se poser la question sur l’avenir de Nagios. Si les propositions inovantes ne sont pas retenues, même si elles sont pertinentes, c’est qu’il y a un problème.

Quel est-il ce problème justement? A mon avis, il vient de l’implémentation actuelle en C. J’aime le C, mais pas pour tout. Quoique l’on peut penser, un scheduler n’est pas un travail de bas niveau. Alors pourquoi Nagios est en C? Car il a plus de 10ans. A l’époque, les langages de plus haut niveaux n’avaient pas totalement fait leur preuve. De plus, je pense que c’est le langage préféré d’Ethan tout simplement. Cette implémentation est bien faite, mais avec du C point de miracle, c’est long à gérer et les possibilités d’erreurs sont multiples. Penser à un pool de process en C effraie, moi le premier. Mais c’est faisable en C avec pas mal d’efforts et de tests, Apache l’a bien fait. Mais dans les langages de plus haut niveaux, les Poll de threads ou de process sont livrés en standards, déjà débuggé et performants.

Ce n’est qu’un exemple parmi tant d’autres sur l’intérêt d’utiliser de tel langages. Bien sûr, si vous voulez coder un driver pour un noyau, un tel langage n’a aucun intérêt, ce n’est pas leur cœur de cible. Mais un scheduler qui a besoin d’être très modulaire l’est. Même un scheduler qui lance des sondes à tout bout de champ.

La solution à la stagnation de Nagios est de passer par un tel langage. Changer quelque chose avec une telle implémentation est faisable, voir même agréable (pas de compilation, langage qui ne pique pas les yeux…). C’est là qu’intervient Shinken. Il était un proof of concept, il devient une proposition pour une nouvelle implémentation. A titre d’exemple, rajouter un attribut a un objet (en gérant l’héritage, la valeur par défaut and co) revient à rajouter une ligne dans le code de Shinken, là où il en demande bien plus dans Nagios. Avoir une idée ne coûtera plus 2h de code, mais quelques secondes.

La proposition

J’ai proposé dans la mailing list devel de Nagios il y a une semaine que Shinken devienne la branche développement pour Nagios 4. Les réponses sont limitées pour l’instant. Ethan ne s’est même pas donné la peine de répondre (lit-il encore cette mailing list?), Andreas va tester un jour. Je vais relancer un peu le sujet, mais j’ai de moins en moins d’espoir d’atteindre mon objectif.

Un autre moyen sera de lancer un concurrent à Nagios, de mettre pas mal de coups de pieds au culs, puis de re-proposer l’inclusion. Mais combien de temps auront-nous perdu dans cette histoire?

Shinken : gestion des noms en UTF8

Posted in Nagios by Nap on December 1, 2009

J’ai voulu m’amuser et mettre des noms en UTF8 pour les hôtes et services. Une fois modifié le character_set des bases merlin et ndo (de base en latin1…) ça a roulé sans problèmes, export en base compris. Merci Python :mrgreen:

Shinken : Quoi de neuf docteur?

Posted in Nagios by Nap on December 1, 2009 4 Comments

Shinken a bien avancé ces derniers temps. Dans le désordre :

  • Support de l’export en base NDO pour MySQL et Oracle (merci à Icinga pour leur fichier Oracle.sql d’ailleurs)
  • Les daemons sont maintenant réellement des daemons (option -d et ils ont leur propre fichier de conf pour choisir par exemple le port et l’interface d’écoute à utiliser)
  • Vérifications des checks orphelins (en gros dans un poller depuis bien trop longtemps)
  • Support du fichier ressource pour les macros $USERN$
  • Tunning mémoire pour les hôtes (utilisation des slots python comme pour les services)
  • Les plugins des brokers ont pris du galon : désormais ils sont configurable dans le fichier de conf principal avec un define plugin. Ils sont après rattachés à un satellite (pour l’instant seul les brokers peuvent les utiliser). De cette manière, il est possible d’instancier un même type de plugin plusieurs fois pour un même daemon. L’exemple le plus explicite de cela concerne la création de deux fichier service-perfdata ou bien l’export dans deux bases ndo.
  • Les plugins des brokers ne peuvent plus faire planter le broker. S’il y a une exception non catchée par eux, le module est désactivé.

La partie NDO n’est pas encore complète, mais le principal est là. Reste à l’optimiser, car pour l’instant la base morfle bien lorsque l’on créé beaucoup de services. La base Merlin est bien plus performante, mais bon, une fois mes cours de SGBD relus, peut être que mes requêtes NDO seront un peu plus efficaces aussi :mrgreen:

Shinken : l’art de l’inspiration

Posted in Nagios by Nap on November 14, 2009

Le partage des idées

Dans tout ce qui est libre on partage le code bien sûr, mais encore plus important on partage les idées. Deux modifications que j’ai apportées ces derniers temps aux Workers (utilisés par les pollers/reactionners) reflètent cela.

Le problème des workers est double : avoir LE bon nombre de Worker et que chaque worker soit le plus efficace possible. Le tout bien sûr pour réduire leur charge au maximum.

Avoir le bon nombre

Le nombre de Worker n’est pas si simple à déterminer. On peut placer un nombre arbitraire (10, 30, 100 ou même 250) mais il ne sera jamais optimal, sauf à faire de nombreuses tentatives. De plus, mesurer leur utilisation n’est pas chose aisée.

Sur un petit environnement, avoir 4 workers sera plus que suffisant. Sur les très gros, 30 n’est pas du luxe. En effet, si on prends un check simple qui fait toujours la même chose, il est relativement simple de savoir combien il en faut. Mais avec des checks qui mettent un temps aléatoire pour s’éxécuter, ça devient tout de suite plus dur.

Après une petite réflexion, leur nombre optimal est venu:

temps_moyen_checks*checks à traiter

Bon le nombres de checks à traiter est plus que facile à obtenir. Le temps moyen des checks un petit peu moins. Je suis parti d’un temps moyen depuis le lancement du daemon mais le problème est que le nombre de checks à la seconde n’est pas tout le temps le même, la nuit ça peut être plus calme par exemple. J’ai utilisé un calculun calcul similaire au load average Unix (une moyenne mobile exponentielle). Ceci permet de ne pas avoir de lisser un peu le nombres de workers demandés le tout en ayant une réactivité intéressante car j’ai pris un load à une minute.

Ceci n’aurait pas été possible si les auteurs d’Unix d’auraient pas utilisés ce type de moyenne et que Linux m’ait montré le code (tout simple en plus..). Au passage j’ai cré une Class spéciale pour ce type de calcul afin de pouvoir le réutiliser dans d’autres parties du code.

Pour l’instant c’est la partie montante du nombre de worker qui est utilisé. Il faut que je m’occupe de la partie descendante (où comment flinguer intelligemment les workers).

Attendre le temps qu’il faut

Revenons un peu sur les temps des checks. Ils sont aléatoires. Souvenez vous : j’ai changé le code du lancement des checks sous Unix par la variante Windows (avec un joli gain de perfs à la clé et une dépendance de moins). MAIS cette technique repose sur une boucle sur poll (pas de select malheureusement :( ) avec un sleep au milieu. OK, il suffit d’attendre le temps du checks… Ah flûte, on ne sait pas a priori combien de temps il va attendre. Attendre trop et c’est de la latence et un worker qui ne fai rien (donc plus de workers nécessaires). Attendre trop pu, c’est une latence minimale, mais un poll lancé trop souvent et donc de la charge inutile…

Bref, il faut attendre le BON temps, ou a défaut le bon ordre de grandeur. Là on peut s’inspirer du TCP.

Oulala, quel est le rapport entre le TCP et une boucle sur le poll? Et bien le slow start de TCP bien sûr! TCP est fait pour tout type de connexions, rapides, lentes, moyennes. Il doit optimiser le débit. Pour cela il augmente dès le début de la connexion le débit envoyé à chaque envoi. Fois 2 à chaque envois. Dès que ça ne passe plus, il a trouvé l’ordre de grandeur, et passe par une augmentation linéaire.

On va utiliser un système similaire. Nous voulons l’ordre de grandeur (une fois qu’on a trouvé, c’est fini). On va donc partir d’une boucle toute simple :

wait_time = 0.0001
while process.poll() is None:
time.sleep(wait_time)

Et la changer en :

wait_time = 0.0001
while process.poll() is None:
wait_time = min(wait_time*2, 0.1)
time.sleep(wait_time)

En une ligne on a une recherche de l’ordre de grandeur. Simple non? Ici j’ai borné à 0.1s. 10 appels systèmes par secondes sont tout à fait acceptable, 10000 beaucoup moins. On change donc un nombre d’appel en O(n) en O(log2(n)).

Il est marrant de voir à quel point les algo les plus remarquables sont toujours d’une simplicité étonnante…

Moyenne mobile exponentielle

Shinken : un nouveau logo

Posted in Nagios by Nap on November 14, 2009 2 Comments

Sur la page de Shinken dans (l’excellent) wiki de nagios-fr (http://wiki.nagios-fr.org/nagios/shinken/start) j’avais placé un petit texte sur un appel à un nouveau logo :

L’auteur n’est pas contre une autre mascotte plus originale (moins manchot) le temps qu’elle respecte l’esprit du logiciel

En effet, le logo que j’avais assemblé au début du projet était le suivant :

shinkenOk il est marrant, mais il a un gros soucis d’image : c’est un manchot. C’est àdire que c’est Très connoté Linux. J’aime Linux, je l’utilise tous les jours, et je suis en train de poster depuis a kubuntu chérie, MAIS pour un programme, le choix d’un logo manchot est à double tranchant : ça fait Linux OK, mais ça ne fait QUE Linux. Or Shinken est multiplateformes. Il faut un logo plus neutre, mais toujours avec la symbolique du Shinken qui coupe.

Romuald FRONTEAU de l’équipe de nagios-fr a donc répondu à mon appel et m’a apporté un nouveau logo que j’aime tout particulièrement :

logo_shinkenSobre, élégant, efficace. Que demander de plus?

Je vais garder mon manchot pour le blog et mettre le nouveau sur les sites du projet Shinken.

Shinken : le choix de la licence AGPL

Posted in Nagios by Nap on November 14, 2009

Au début de l’écriture de Shinken s’est vite posé le choix de la licence. Ou plutôt le choix de la licence libre pour être plus exact. La BSD ou tout autre licence qui permet de prendre le code, de le placer dans du code propriétaire sans rien retourner à la communauté n’est pas à mon goût. Certains l’acceptent bien, moi non. Le choix de la GPL est vite arrivé comme un standard.

Ensuite le problème des services distants se pose avec la GPL, d’où le choix final de l’AGPL qui impose à un fournisseur de service de fournir le code à ses clients s’il utilise le code en AGPL.

Je viens de lire http://www.framablog.org/index.php/post/2009/11/13/pourquoi-j-utilise-la-licence-gpl (traduction de http://zedshaw.com/blog/2009-07-13.html) et ça me conforte dans ce choix.

Shinken : un serveur? Inutile, préférez un eeepc…

Posted in Nagios by Nap on November 10, 2009 2 Comments

Hier je me suis amusé à voir jusqu’où pouvait aller Shinken en terme de perfs sur un eeepc 701 (le tout premier pas super puissant). Et bien il s’en tire plus qu’honorablement : 10000Checks/5min. C’est largement suffisant pour bon nombre d’installations. Bref, n’achetez plus de serveur pour votre supervision, prenez plutôt des eeepc, c’est beaucoup moins cher…

Voici les specs du monstre :

eeepcEt ce que donne shinken (ici l’ordonnanceur) :

shinken-eeepcJe préfère m’abstenir de faire un bench avec Nagios sur cette machine :mrgreen:

Et bientôt une grande nouvelle concernant le logo de Shinken ;-)

« Previous PageNext Page »