Shinken 0.5 : le ver de terre entre en éruption

Posted by on 26 Jan 2011 in Planet, Shinken, Supervision | 0 comments

Logo Shinken 0.5Bonjour à tous,

Shinken sort déjà une nouvelle version, un peu plus d’un mois et demi après la dernière! Cette version 0.5 (nom de code ver de terre éruptif) continue sur la même lignée que son prédécesseur, et sur un rythme toujours effréné. Comme à son accoutumée, elle est disponible sous forme classique et sous forme d’une machine virtuelle de démonstration.

Outre les quelques corrections de bugs, nous avons le droit à cinq 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 métiers!

Regardons un peu les dernières fonctionnalités plus en profondeur.

Périodes d’absences pour les contacts

Les administrateurs sont comme tout le monde, ils partent de temps en temps en vacances. Lors de leur retour, chacun faisait à peu près la même chose : prendre toutes les alertes s’étant produites pendant ses congés et les supprimaient. Dorénavant, avant de partir il peut prévenir l’outil qu’il ne sera pas là sur une période de temps, et ce dernier ne va tout simplement pas lui lever de notifications pendant celle-ci.

Escalades de notifications basées sur le temps

Dans Nagios, les escalades de temps sont basées sur un nombre de notifications. Ceci rend cette configuration très complexe lorsqu’il est question de SLA basés sur le temps. Or la plupart le sont (comme par exemple escalader le problème au support niveau 2 au delà de 3h).

Shinken ajoute ceci dorénavant. Ce rajout n’est pas un simple « temps=nombre de notifications/temps entre les notifications » car il gère le cas où l’administrateur a décidé qu’entre deux notifications il faille 1 journée, mais qu’il faille escalader au bout de 3heures. L’outil va savoir qu’au bout de 3 heures il doit escalader le problème sans attendre une prochaine notification pour cela.

La notion de criticité

Les outils à licence libre ont un souci : 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 du monde Nagios/Shinken, il n’y avait que 3 états : 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é de ses objets. Ils seront triés comme il faut dans les consoles temps réels. 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 switch qui impacte des applications de production) sa criticité est calculée avec la valeur maximale de celle de ses impacts.

Ainsi, il est possible de lever une alerte la nuit pour un administrateur réseaux pour un switch défaillant que si celui-ci à réellement impacté un service important et non pas un de qualification.

Voici un exemple de vue dans Thruk qui présente les « problèmes sources » et uniquement eux, le tout trié par criticité :

Vue des problèmes sources par Thruk, avec tri sur la criticité

Vue des problèmes sources par Thruk, avec tri sur la criticité

Une telle vue peux être résumée simplement pour les administrateurs « faites ceci, et dans cet ordre ».

Les règles métiers, ou business rules

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. 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 ».

C’est ce que propose Shinken. Désormais, une simple commande de supervision permet d’obtenir une telle règle « complexe ». L’exemple donné dans la documentation est la suivante, pour décrire une application complète :

  • deux bases de données redondées
  • trois services webs, dont au moins deux sont nécessaires pour cause de charge
  • deux répartiteurs de charges redondés

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 après tout c’est un objet comme les autres d’un point de vue externe.

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

Voici un exemple de ce que ceci peux donner :

Thruk et vue business trié par criticité

Thruk et vue business trié par criticité

Et après?

La prochaine version de Shinken devrait introduire des fonctions avancées sur les connexions réseaux 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.

Leave a Comment