Shinken 0.5 : la supervision au pas de charge

Shinken, l'outil de supervision pleinement compatible avec Nagios écrit en Python [1], sort une nouvelle version un peu plus d’un mois et demi après la précédente !

Cette version 0.5 au doux nom de code imagé ver de terre éruptif continue sur le même rythme effréné. Comme à son accoutumée, elle est disponible sous forme classique et sous forme d’une machine virtuelle de démonstration [2].

Outre les classiques corrections de bugs, on peut noter cinq nouvelles fonctionnalités principales.

• Rajout du chiffrement SSL entre les processus, basés sur des certificats ;


• Des périodes d’absences pour les contacts ;


• Les escalades de notifications basées sur le temps, afin de mieux coller aux notions de SLA ;


• L’arrivée de la notion de criticité des hôtes et services ;


• Et la dernière mais pas la moindre : l’arrivée dans le cœur de l’application des règles de corrélations d'états !

Si la première fonctionnalité parle d'elle même, ce n'est pas le cas des quatre autres. Regardons-les d'un peu plus près.

Périodes d’absences pour les contacts

Les administrateurs partent en vacances comme tout un chacun. Lors de leur retour, ils font tous à peu près la même chose : supprimer toutes les alertes s’étant produites pendant leurs congés. Dorénavant, avant de partir, il peut prévenir l’outil qu’ils ne seront pas là sur une période de temps, et ce dernier ne va tout simplement pas leur envoyer de notifications pendant leur repos bien mérité.

Escalades de notifications basées sur le temps

Dans Nagios, les escalades de temps étaient basées sur un nombre de notifications. Ceci rend cette configuration très complexe lorsqu’il est question de SLA qui sont — eux — basés sur le temps.

Shinken ajoute cette fonctionnalité dorénavant. Cette gestion prend en compte les cas d'intervalles de notifications larges qu'il faut abréger pour escalader le problème. La configuration d'une règle du type « escalade le problème au niveau 2 au bout d'une heure, et au niveau 3 au bout de quatre » n'aura jamais été aussi simple.

La notion de criticité

Comme tous les outils de supervision libres, Shinken doit faire face à un problème original : les administrateurs n’ont aucun remord à mettre en supervision tout leur parc, car ils n’ont pas à payer de licence pour chaque objet supervisé. Ceci signifie qu’ils supervisent aussi bien de la production que des serveurs moins critiques comme ceux de qualifications.

Or, dans les consoles de supervisions actuelles de l'écosystème Nagios/Shinken, il n’y avait que trois états pour tout ce joli monde : ok, avertissement et critique. Mais un avertissement sur un serveur de production peux être plus important qu’un critique sur un serveur de qualification.

C’est pour gérer cela que Shinken permet désormais aux administrateurs de définir la criticité des objets. Ceci permet aux consoles de les trier par ordre de criticité, aidant les administrateurs à identifier rapidement ce qui est important de ce qui l'est moins. Un point important sur le fonctionnement de ce mécanisme vient du fait que lorsqu’un « problème source » est détecté (comme sur un commutateur réseau qui impacte des applications de production), sa criticité est calculée avec la valeur maximale de celle de ses impacts.

Ce mécanisme est également utile pour filtrer les notifications. Il est possible de lever une alerte la nuit pour un administrateur réseaux pour un commutateur défaillant que si celui-ci a réellement impacté un service important et non pas en cas de défaillance d'un commutateur de qualification par exemple.

Pour l'instant seule l'interface Thruk [5] utilise ces informations de visualisations, mais gageons que d'autres suivront cette voie.

Les règles métiers, ou la corrélation d'états

Il existait déjà dans le monde Nagios un addon permettant d’avoir une « agrégation d’états » sur un indicateur unique avec Nagios Business process addon [6]. Mais il était intéressant d’incorporer un tel fonctionnement dans le cœur de la supervision, afin d’avoir les autres rajouts comme les relations problème source/impacts ou la criticité liés à ces objets « business ».

Désormais, une simple commande de supervision permet d’obtenir une telle règle « complexe ». Voici un exemple tiré de la documentation pour décrire une application web classique complète :

• deux bases de données en redondance ;
  
• trois services web, dont au moins deux sont nécessaires pour cause de charge ;
  
• deux répartiteurs de charges en redondance.

Une telle règle va s’écrire simplement comme commande de supervision :
bp_rule!(base1|base2) & (2 of: http1 & http2 & http3) & (lvs1 | lvs2)
Un tel hôte ou service est ainsi affichable avec n’importe quelle interface, car c’est un objet comme les autres d’un point de vue externe.

Certains outils comme Thruk (encore lui) sont cependant capables d’interpréter les données du module LiveStatus de Shinken et de représenter ces objets sous forme d’arbres [4].

Et après ?

La prochaine version de Shinken devrait introduire des fonctions avancées sur les connexions réseau afin de pouvoir les « inverser » à loisir et ainsi être plus facile à intégrer dans des environnements hautement sécurisés.

Pour rappel, vous pouvez rajouter votre idée ou voter pour votre future fonctionnalité favorite sur le site http://shinken.ideascale.com.

Aller plus loin

• Site officiel (85 clics)
• Téléchargement (21 clics)
• Source (38 clics)
• Captures d'écrans (44 clics)
• Thruk (21 clics)
• Nagios Business process (20 clics)