Introduction


L'état de supervision d'un service ou d'un hôte est déterminé par 2 composants :

Il y a 2 types d'état dans Shinken Enterprise  - état SOFT et état HARD .Ces états sont primordiaux dans car ils sont utilisés pour déterminer quand les vévénemenst sont exécutés et quand les notificatiosn sont envoyées. 

Ce paragraphe décrit les différences entre état SOFT et état HARD ,quand ils s'appliquent et ce qui se passe quand ils s'appliquent.

Relance des vérifications de service et d'hôte 


Afin d'éviter les fausses alarmes liées aux états transitoires, Shinken Enterprise permet de définir combien de fois un service ou un hôte doit être (re)vérifié avant d'être considéré comme ayant un réel problème . Ceci est contrôlé par le paramètre  "max_check_attempts" dans la définition des services et des hôtes. Il est important de comprendre comment sont (re)vérifiés les hôtes et services afin de comprendre les différents types d'état.

 

Etat "Soft"


L'état "Soft" apparaît dans les conditions suivantes :

Les points suivants apparaissent lorsqu'un service ou un hôte subissent un changement d'état "SOFT" :

L'état "SOFT" est tracé uniquement si vous avez activé les paramètres "log_service_retries" ou "log_host_retries" dans le fichier principal de configuration. 

Le plus important lors d'un état "SOFT" est le lancement du traitement d'événements. Utiliser le traitement d'événements peut être très pratique si vous essayez de régler pro activement un problème avant que l'état ne passe en "HARD". Les macros $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront la valeur "SOFT" lorsque les événements sont exécutés, ce qui permet au script de savoir quand il est nécessaire de réaliser des actions correctrices. Plus d'informations disponibles dans le paragraphe <advanced/eventhandlers>`.

Etat "Hard"


L'état "Hard" apparaît dans les conditions suivantes :

Les points suivants apparaissent lorsqu'un service ou un hôte subissent un changement d'état "HARD":

Les valeurs $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ sont à "HARD" lorsque les événements sont exécutés ce qui permet au script de savoir quand il est nécessaire de réaliser des actions correctrices

Exemple


Voici un exemple de comment sont déterminés les types d'état quand un changement apparaît, et quand les événements et les notifications sont lancés. L'exemple ici montre le résulta de checks consécutifs, la valeur de du paramètre max_check_attempts étant à 3.

TempsNombre de CheckType d'étatType d'étatChangementNotes
01OKHARDNonEtat Initial
11CRITICALSOFTOui1ère détection d'un état non-OK Lancement d'événements 
22WARNINGSOFTOuiLe check continue d'être en non-OK . Exécution des événements. 
33CRITICALHARDOuiLe nombre maximum de check est atteint donc l'état passe à "HARD" . Exécution des événements et envoi d'une notification sur un problème. Le nombre de check est remis à 1 aussitôt après.
41WARNINGHARDOuiLe check passe en état HARD WARNING . Exécution des événements et envoi d'une notification sur un problème
51WARNINGHARDNonLe check se stabilise en état "problème HARD" . En fonction de la définition de l'intervalle défini pour un service, une autre notification peut être envoyée.
61OKHARDOuiLe check repasse en état HARD . Exécution des événements et envoi d'une notification de reprise
71OKHARDNonLe check est toujours OK.
81UNKNOWNSOFTOuiLe check est détecté comme passant de l'état "SOFT" à "non-OK" . Exécution des événements
92OKSOFTOuiLe check revient à un état SOFT . Exécution des événements, mais pas d'envoi de notification car il ne s'agissait pas vraiment d'un problème. L'état est passé à "HARD" et le nomre de check repasse à 1 aussitôt après.
101OKHARDNonLe check se stabilise en état OK .