Les escalades de notifications enfin simples à mettre en place

Posted in Shinken by Nap on January 25, 2010

J’ai rajouté dernièrement le support des escalades de notifications. Pour rappel, elles permettent d’envoyer à d’autres contacts les notifications lorsqu’un problème persiste. Par exemple, vous pouvez définir pour le service CPU sur main-server un escalade qui va prévenir les chefs si au bout de 3 notifications le problème n’est pas résolu :

define serviceescalation{
host_name       main-server
service_description      Load
contacts                 chef, grandchecf, coupeurdetete
first_notification       3
last_notification        0
notification_interval    20
escalation_period        24×7
escalation_options       w,u,c,r
}

Cependant, cette forme de définition pose un problème : elle va s’appliquer sur des éléments, ici des services, au lieu d’être appelée par ces éléments.

Par clair? Disons qu’ici pour l’utiliser sur un service c’est sympa, mais en général on aimerait bien l’avoir pour un groupe de service, ou un groupe d’hôte, saufs certains service ou hôtes, etc. Bien sûr on a la possibilité de mettre * ou hostgroup_name, mais c’est vite limité. Bref, avoir la possibilité d’avoir une véritable gestion par des techniques d’héritages pourrait être utile (additif et implicite notamment).

De plus, quand on y pense, ici encore on a bien souvent un héritage host-> service non? Genre si la machine serveur-1 tombe, on aimerait bien avoir cette même règle sur les services de cette machine. Mais Nagios ne pospose ue serviceescalation et hostescalation, donc c’est pardu pour l”héritage, surtout quand c’est une application sur des éléments, et non un appel de ces éléments.

C’est pourquoi j’ai rajouté un nouvel object dans Shinken : escalation. Bah oui, ni service, ni host. Ca a un air de déjà vu pour la définition :

define escalation{
escalation_name        ToBoss
contacts                 chef, grandchecf, coupeurdetete
first_notification       3
last_notification        0
notification_interval    20
escalation_period        24×7
escalation_options       w,u,c,r
}

Et après on l’appel depuis un hôte :

define host{
[...]
escalations        ToBoss
[...]
}

Après si on ne défini rien sur les services de cet hôte, ce paramètre sera automatiquement hérité (TODO : rajouter une option pour hériter implicitement ou non certains champs). Et avec une telle définition, c’est ultra simple de le rajouter dans les templates qu’il faut, et hop, la gestion des escalade faciles. Ceci me permettra peut être de réellement les utiliser un jour, car dans leur état actuel, leur définition est un véritable cauchemars sur les grands environnements…

Gestion des exclusions de timeperiods

Posted in Shinken by Nap on January 6, 2010

Et bien après une bataille qui avait des air de guerre épique, j’ai mis en place les exclusions de timeperiods. Après une première version un peu … bourrine, une nouvelle arrive qui passe les tests et qui en plus est rapide. Cette partie du code n’est pas celle que je préfère, car il faut dire que les problèmes des dates et de calcul d’intervalle, c’est touffu, surtout lorsque l’intervalle ressemble à ‘monday 3 – thursday 4 00:00-11:00,12:00-24:00‘ (soit entre le troisième lundi du mois et le 4ième jeudi). Et puis le plus marrant dans ces définitions, c’est que c’est relatif par rapport au moment où vous calculer…

Mine de rien, c’est sûrement la partie la plus complexe de l’outil. Bon je ne vais pas me plaindre, le module time de python a bien aidé. Bref, vous pouvez faire une déclaration du genre :
define timeperiod{
timeperiod_name 24×7
alias 24_Hours_A_Day,_7_Days_A_Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
exclude workhours
}

# ‘workhours’ timeperiod definition
define timeperiod{
timeperiod_name workhours
alias Normal Work Hours
monday 09:00-17:00
tuesday 09:00-17:00
wednesday 09:00-17:00
thursday 09:00-17:00
friday 09:00-17:00
}

Donc ici 24×7 sera sans les workhours (bon bah c’est un exemple hein, à vous de trouver quelque chose de plus utile….). Donc un check en 24×7 voulant être lancé vers 10h le sera à 17h en fait. Ceci gère aussi si les timeperiods dans exclude ont elles même des exclude bien sûr.

Après MySQL, Oracle et couchdb : Sqlite

Posted in Shinken by Nap on January 4, 2010

Voici l’arrivée dans Shinken du support du schéma Merlin sous Sqlite (merci Python pour le support natif et simple). Sqlite permet d’avoir une base de données à peu de frais, directement dans un fichier, sans tout le bordel qu’il y a autour lorsque l’on souhaite une petite base simple en local.

Les applications tierces n’auront plus d’excuses pour encore utiliser les fichiers plats, là on fait du Select en un temps records, installation de la base comprise.

La configuration du plugin est simple :
define plugin{
plugin_name ToMerlindb_Sqlite
plugin_type merlindb_sqlite
database_path /data/mabase.sqlite
}