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 ;-)

Shinken : 100Kchecks? Ah désolé, il fallait lire 200K

Posted in Nagios by Nap on November 9, 2009

Et oui désolé, mais le 100K checks/5min n’est plus de mise, désolé. C’était un compte rond, facile à retenir, mais non, il n’est plus.

Il faut parler de 200K désormais (dans les même conditions donc Xeon 4coeurs) :mrgreen:

La limitation n’est plus du fait du poller désormais, mais bien du scheduler. Et tout ça c’est à cause de Windows. En effet, je me suis demandé ce que donnait l’exec que j’utilise sous Windows sur Linux, donc sans passer par pexpect. Et bien les perfs sont autrement meilleures sans. Donc bye bye la lib, retour à la mano (10lignes, ça va…). Ceci m’a permis au passage de limiter le nombre de Workers en cours et donc de limiter fortement le load average de la machine, ce qui ne me déplais pas, c’est bien plus contrôlable.

Avec une telle conf, la machine arrive à avoir 25% de CPU en idle, le scheduler lui est très sollicité (principalement par les échanges Pyro/cPycle). Je me demande à combien on peut monter en mettant un poller et deux schedulers…

Pour la preuve au fait:

mysql> select count(*),avg(latency) from service;
+———-+—————–+
| count(*) | avg(latency)    |
+———-+—————–+
|   200005 | 13.173913548248 |
+———-+—————–+
1 row in set (0.30 sec)

PS: pas de capture de ninja ça coup-ci, la page part en timeout… trop de services à gérer…

Shinken : à oui au fait, c’est multiplate-forme

Posted in Nagios by Nap on November 5, 2009

Shinken est écrit en Python et ses deux dépendances principales sont Pyro et Pygraph qui sont disponibles sur toutes les plate-formes où est Python (c’est à dire beaucoup). J’ai fait un test, et après quelques petits aménagements très légers (10 lignes…) dans la partie lancement des checks et autres, j’ai réussi à lancer Shinken sous Windows :)

Une petite preuve çi-dessous:

shinken-on-windowsEn fait j’ai dû bypasser la partie lecture du pipe nommé nagios.cmd pour que ca marche, les pipes nommées sous Windows n’étant pas gérés directement (ni simplement…). Mais tout le reste fonctionne comme sur un Linux :)

Certains vont se demander à quoi ça sert. Alors:

  • ca coûte rien de le porter pour Windows, alors faut pas se priver
  • Shinken gère les très grands environnements avec le découpage de conf and co (là où Nagios péchait par manque de perf et l’architecture distribuée hautement disponible), mais il ne faut pas oublier que Nagios est aussi exclu des PME à cause de la nécessité d’avoir un Linux (la solution cygwin n’est pas acceptable ni recommandée…). Shinken permet de ne plus avoir ce problème et offre à Nagios un nouveau terrain de jeu, et non des moindres.

Reste à voir si Ninja est prévu pour Windows, et après on peut penser à un pack Shinken/Ninja/Pyhon/Xampp.

Questions performances le lancement de process sous Windows coûte cher. Ici la machine est très chargée, mais bon elle avait 1500 checks/5min et surtout c’était une VM (faut pas trop lui en demander). Sous Windows ça sera les petits environnements, donc 1500 checks c’est déjà pas si mal :)

Dernière info : l’installation de python et des dépendances de shinken sous un Windows est une véritable partie de plaisir, un grand bravo aux auteurs de Python et leur processus d’installation sous Windows, car ça marche très bien, c’est un vrai next/next/next :)

Aller vraiment la dernière : là c’est un XP, mais ça roule de la même manière sur un Seven :mrgreen:

Shinken : les realms sont là

Posted in Nagios by Nap on November 3, 2009

Ca y est, j’ai implémenté les Realms et tout ce que ça implique sur le dispatching des configurations et la gestion des spares. Une configuration l’utilisant va devenir par exemple :

define realm {
   realm_name       All
   realm_members    Europe,US,Asia
   default          1    ;Est le realm par défaut. Doit être le seul dans ce cas...
}
define realm{
   realm_name       Europe
   realm_members    Paris   ;Le realm Paris est contenu dans Europe
}
define reactionner{
       name	reactionner-All
       address	localhost
       port	7769
       spare	0
       realm    All
       }

define poller{
       name     poller-All
       address  localhost
       port     7771
       spare    0
       realm    All
       manage_sub_realms  1
}

define broker{
       name	broker-All
       address	localhost
       port	7772
       spare	0
       realm    All
       }

Ici c’est un cas très simple, sans spare (et avec des realms un peu vide…) mais qui montre un peu la conf que cela va donner.

Il ne me manque plus qu’à gérer le cas où l’administrateur n’en a défini aucun (ce qui sera pour les petites et moyennes configurations). Dans ce cas je vais en créer un à la volée et mettre tout le monde dedans tout simplement :)

Shinken : Pool -> Realm

Posted in Nagios by Nap on November 1, 2009

Bonjour,

Petit changement cosmétique pour les pools. Ils ne s’apellent plus comme ça, je préfère utilisé realms à la place. Il y aura beaucoup moins de confusion avec les pools. Si certains ne savent pas ce que signifie ce terme, il y a wikipedia  http://en.wikipedia.org/wiki/Realm.

Bon c’est parti pour du query remplace maintenant…

Shinken : la notion de pool, ou comment pousser encore plus loin l’architecture

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

L’illumination du jour

Bonjour,

Hier j’ai eu tout le temps de pousser l’architecture de Shinken plus loin que je ne l’avais fait jusqu’alors. En effet, elle permet dans sa forme actuelle d’avoir un point unique d’administration de plusieurs ordonnanceurs, pollers, reactionners et brokers. Les hôtes sont dispatchés sur les ordonnanceurs, les services suivent, les satellites (poller/reactionner/broker) tapent sur tous les ordonnanceurs. C’est implémenté, et le pire, c’est que ça fonctionne. Tout le monde est content.

Tout le monde? Non. Un petit village d’irréductibles gaul… oups, je m’égare…

Tout le monde? Non. Imaginons un peu qu’un administrateur ait une infrastructure distribuée sur plusieurs continents (un quelconque rapport avec l’infra de l’auteur est fort plausible…). Avec l’archi de Shinken actuellement, si l’administrateur a mis deux ordonnanceur : un a Bordeaux et un à Shangaï (toujours par le plus grand des hasard hein…) et de même un poller sur Bordeaux, et un sur Shangaï, les pollers tapent sur les deux ordonnanceurs, et pour ceux qui n’ont pas le grand bonheur d’avoir un site à shangaï, autant vous dire que les lignes internet sont plutôt… bon disons que c’est aléatoire pour rester poli. De plus, un hôte va se voir affecté sur un ordonnanceur ou un autre sans pouvoir influer dessus.

Bref, Shinken, dans son état actuel, est pratique pour avoir de la haute dispo, répartition de charge et performance mais pour un site unique. Et là vous me voyez venir à des kilomètres : la gestion des sites.

Un pool, des pools

Alors on va utiliser un nom plus général qu’un site (après tout ça peut être une séparation plus organisationnelle que géographique) : un pool. (A ne pas confondre avec les pollers donc).

Un pool est un groupe de ressources indissociables auquel vont pouvoir être rattachés des hôtes ou des groupes d’hôtes. Une telle association sera unique, un hôte ne pourra se trouver que dans un pool donné et il faudra que ses parents soient dans le même pool (sinon le découpage de conf et le dispatchign ne sera pas content). Si ces derniers n’ont pas de pool désignés, il hériterons de celui-là.

Un pool est donc un groupe de schedulers, pollers, [reactionners], [brokers] (les deux derniers sont optionnels). Dans un pool, les pool vont se connecter à tous les schedulers du pool.

Un pool peut contenir un autre pool. Ceci ne change rien pour les ordonnanceurs/pollers, ceux-ci ne s’adressant qu’aux ordonnanceurs du même pool. Les hôte d’un pool ne seront dispatchés que sur les schedulers du pool, pas de ses fils. Là où une hiérarchie de pool devient utile concerne les reactionners/brokers : ils sont associés à un pool, mais si ce dernier contient d’autres pools (qui eux même en contiennent d’autres etc etc) et bien les reactionners/broker vont chercher les infos sur tous les ordonnanceurs de la hiérarchie de pool.

En fait, cette notion de satallites qui peuvent atteindre les sous-pools devrait être paramétrable, genre une option acces_inner_pool avec comme valeur par défaut les pollers a 0, et les reactioners/broker 1. Si après l’administrateur veux le changer pour décloisonner/cloisonner, libre à lui.

Il faut bien retenir une chose : un seul Arbiter (et son spare) et une seule conf, quelque soit le nombre de pools que vous avez. Ah une autre chose : pour l’instant rien n’est implémenté! Mais bon ça ne devrait pas être trop méchant je pense.

Au secours, je comprends rien!

Pas clair? Oui je m’en doute un peu, avec mes pools, sous-pool, pollers et schedulers.

En résumé, vous mettez un hôte ou un groupe d’hôte dans un pool. Celui-ci est un ensemble de ressources pour superviser vos hôtes et les services qui y sont raccrochés. Vous pouvez enlever ou rajouter des ressources au pool sans avoir à changer la conf des 30K hôtes que vous avez patiemment configuré car vous avec rajouté un ordonnanceur ou un poller de plus dans le lot.

Bref, le pool est une facilité pour gérer ses ressources. Si vous n’avez qu’un petit site gérable par un ordonnanceur/poller/reactionner/broker, pas la peine de vous embêter avec un pool, par défaut shinken en créera un pour vous à la volée et vous n’en entendrez même pas parler :)

Dessine moi un diagramme

Des diagrammes, c’est encore mieux que toutes ces explications :)

Imaginons que l’on a deux environnements distribués un peu partout dans le monde. Dans un cas, on souhaite un cloisonnement total des continents. Dans un autre, on accepte que les réactionners et brokers soient communs à tous les ordonnanceurs du monde (oui, rien que ça :) ).

Les diagrammes

Voici le cas isolé :

shinken-architecture-isolated-pools

Et le cas plus communs avec les réactionner/broker de communs :

shinken-architecture-global-poolComme vous pouvez le voir, les éléments sont raccrochés à un seul pool. suivant l’héritage qu’on leur a donné, ils utilisent les ordonnanceurs des sous-pool ou non.

Et dans la conf, ça donne quoi?

Voici ce que ça devrait donner pour le second cas :

define pool {
pool_name    All
pools         Europe, US, Asia
}
define pool{
pool_name    Europe
pools                Paris
}

(je ne sais pas encore si c’est bien utile de forcer la définition des autres pools même s’ils n’ont qu’un nom…).

define scheduler{
scheduler_name       sched Paris
pool                                 Paris
}
define reactionner{
reactionner_name   reactionner-maitre
pool                        All
}

Et dans les hôtes :

define host{
host_name         serveur-paris
pool                       Paris
[...]
}

Pour ces derniers ce paramètre sera géré par l’héritage comme toutes les propriétés des hôtes.

Ce qui est susceptible de changer

Il me reste quelques petits points à voir : doit-on faire le lien entre les schedulers/pollers/reactionners/broker et les pools au niveaux du define des pools, ou bien comme ci-dessus au niveau des éléments? Les deux? Mais quoi faire en cas d’incompatibilité des deux types de configuration? Je prends tout commentaires :)

Shinken : dispatch des commandes externes

Posted in Nagios by Nap on October 24, 2009

Des commandes importantes

Nous avons déjà vu le dispatch des configurations vers les schedulers et les satellites, regardons désormais comment se passe l’envoi de commandes externes par le client. Dans la philosophie Shinken, celui-ci n’a besoin d’envoyer ses ordres que d’un seul endroit, à côté de l’Arbiter.

Il faut séparer les commandes en deux catégories :

  • les commandes globales à tous les ordonnanceurs;
  • les commandes spécifiques à un élément (host/service/contact).

En fait une partie des deuxièmes commandes est en fait globale : les contacts sont partout et les commandes les concernant sont envoyées partout.

Comment shinken les dispatch

En fait ce n’est pas sorcier. Pour chaque type de commande Shinken sait s’il elles sont globales ou non. Pour les globales, il ne se pose pas de question, il envoie à tout le monde et voila.

Pour les spécifiques, il faut qu’il trouve quel est l’ordonnanceur en question. Il cherche pour cela dans les N configurations l’élément impacté (hôte ou service). Une fois trouvé, il sait à qui envoyer l’ordre et il le fait.

Une fois les ordres reçus, les ordonnanceurs n’ont plus qu’à les appliquer.

? Vous voulez un diagramme? Bon ok, voici un exemple avec une commande spécifique et une globale.

shinken-external-commands

Shinken : le dispatching des configurations et les spares

Posted in Nagios by Nap on October 23, 2009 4 Comments

Rappel sur les daemons et les configurations

J’ai déjà évoqué le fait que Shinken utilise plusieurs daemons qui ont chacun leur rôle. Le maître de tous est l’Arbiter qui lit la conf, la découpe et l’envoie vers ses petits camarades. Bien sûr, les satellites comme les pollers ont besoin de connaître l’adresse des ordonnanceurs. Ces derniers ont la responsabilité de l’ordonnancement de la supervision. La perte d’un d’entre eux peu être embêtante : une partie des hôtes ne seront plus surveillés!

C’est pourquoi Shinken utilise un système de spare : des daemons seront lancés mais non actifs. Ils ne se verront affecter une configuration et donc une responsabilité que si un daemon maître meurt. Typiquement un placement de ces spares sur la machine de l’Arbiter peut être utile, il y a peu de chance qu’elle perde le lien avec elle même.

Regardons un peu le dispatching des configurations vers les ordonnanceurs et ce qui se passe lorsqu’un ordonnanceur n’est plus disponible

Dispatch des configurations

L’arbiter lit la configuration globale de l’administrateur, il la coupe en morceaux (autant que l’ordonnanceurs NON spare). Le dispatcheur (une Classe dans l’Arbiter), l’envoi vers les ordonnanceurs. Puis il créé une configuration particulière avec juste les adressess des ordonnanceurs à destinations des satellites comme les pollers ou le broker. Et hop, tout le monde est content.

Ca se résume en un diagramme:

shinken-conf-dispatching

Lorsqu’un ordonnanceur tombe

Personne n’est parfait, les OS non plus. Une machine ca peut tomber, un réseau aussi. Bref, les daemons ne seront pas toujours joignables. C’est pour cela qu’on peut définir des spare qui vont reprendre le flambeau des vérifications. Pour l’instant, seul les ordonnanceurs peuvent avoir un spare, mais ca ne devrait pas tarder pour les satellites car ce n’est pas bien différent.

L’Arbiter vérifie régulièrement que tout le monde est vivant. Si un ordonnanceur est déclaré mort alors qu’il avait la responsabilité d’une configuration, il envoie la configuration vers un spare disponible.Il met à jour les informations des satellites pour qu’ils prennent en compte cette nouvelle disposition.

Un cas intéressant arrive lorsque l’ordonnanceur n’était pas disponible à cause d’une perte réseau (vous savez, cette grande variable aléatoire :mrgreen: ). Il était encore vivant mais on ne le voyait plus c’est tout. Si la conf a été envoyé à un spare, on a un problème : deux ordonnanceurs avec la même conf. Pour l’instant il est demandé à l’ordonnanceur maître de gentiment arrêter son ordonnancement et d’attendre une nouvelle conf. Dans l’avenir, une solution plus élégante sera de demander plutôt au spare de lâcher la main, car il y a de fortes chances que ce dernier aient moins d’informations que le premier.

Ca se résume en un diagramme :

shinken-scheduler-lostEn bref

Imaginez un même système en C (juste le dispatching et la gestion des spares). … Ca y est vous le voyez? Compter le nombre de lignes que ca demande. … Combien alors? Tout ça? Maintenant regardons combien ce prends dans Shinken : dispatcher 200 lignes, satellitelink 100 lignes (et ca va fortement diminuer), satellite pour la gestion de la conf : 50 lignes. Ah oui,  le tout avec 30% de commentaires :-)

Le Python c’est bon.

« Previous PageNext Page »