Shinken 0.5 : le ver de terre entre en éruption

Bonjour à 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é

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é

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.

RSur le même sujet:

1. Shinken 0.4 : la libéllule décadente se pose L’équipe de Shinken vient de sortir une nouvelle version de son outil de supervision. Étape importante pour ce projet, c’est la première a être validée pour installation en production ! Un rattrapage des derniers manques par rapport à Nagios Comme à leur habitude, les développeurs...
2. Shinken : Le brame du Caribou Et oui, encore une nouvelle version de Shinken et un nom de code sorti d’une imagination on ne peux plus tordue. Cette version 0.3 nommée Crappy Caribou (littéralement Caribou dégueux) est sortie ce 5 octobre. Elle fait suite à la 0.2 (Blaireau chauve) en un...
3. Shinken : Le blaireau sort de sa tanière Source : http://www.shinken-monitoring.org/news/the-0-2-version-is-out/ Comme énoncé lors de la conférence de Jean Gabès aux RMLL 2010, l’arrivée de la version 0.2 de Shinken surnommé « Bold Badger » est sortie courant septembre. Pour le moment, vous pouvez tester la version 0.2 en installant Shinken via les sources (la...
4. Le fugu sans peur, aka Shinken 0.6, est lâché Les auteurs de Shinken viennent de publier leur dernières avancées sur ce projet. Cette version est dans la continuité de ce qu’ils nous on habitués, avec de nouvelles fonctionnalités très intéressantes. Un module de découverte! Le grand rajout de cette version est incontestablement le module...
5. Changement d’adresse pour « business process addon » Business process addon permet d’agréger des points de contrôle techniques sous forme d’une vue par application. Une application étant constituée d’un ensemble de briques techniques (serveurs, services ….), business process addon vous permet non seulement de bénéficier d’une vue dédiée à l’état global d’une application,...