Introduction

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

• le statut de l'hôte ou du check ( Ok, Attention, Critique, ou Inconnu )

• le type d'état dans lequel se trouve le l'hôte ou le check, aussi appelé la "Confirmation de Statut" dans l'UI de visualisation. Il y a 2 types d'états dans Shinken Enterprise : l'état SOFT et l'état HARD.

Ces états sont primordiaux car ils sont utilisés pour déterminer quand les événements sont exécutés et quand les notifications sont envoyées. 

Ce paragraphe décrit les différences entre état SOFT et état HARD, quand ces états s'appliquent, ainsi que les actions qui en découlent.

Relance des vérifications d'hôtes et de checks

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 checks et des hôtes. Il est important de comprendre comment sont (re)vérifiés les hôtes et checks afin de comprendre les différents types d'état.

Etat "SOFT"

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

• quand le résultat de la vérification d'un check ou d'un hôte n'est pas OK, et que le check n'a pas encore été revérifié le nombre de fois défini dans le paramètre "max_check_attempts"  C'est ce qu'on appelle une erreur "SOFT", le statut n'est pas confirmé.

• quand un check ou un hôte revient d'un état "erreur SOFT". C'est ce qu'on appelle une reprise "SOFT".

Le point suivant apparaît lorsqu'un check ou un hôte subit un changement d'état "SOFT" :

• le traitement d'événements est lancé pour gérer l'état "SOFT" .

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 notations de remplacement de contenu $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 la page des Gestionnaire d'événements.

Etat "HARD"

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

• quand le résultat de la vérification d'un service ou d'un hôte n'est pas OK, et que le check a déjà été revérifié le nombre de fois défini dans le paramètre "max_check_attempts"  C'est ce qu'on appelle un erreur "HARD", le statut est alors confirmé.

• quand un hôte ou check passe d'un état d'erreur à un autre état d'erreur  ( e.g. WARNING à CRITICAL ).

• quand le résultat de la vérification d'un check ou d'un hôte n'est pas OK et que l'hôte associé est dans un état DOWN ou UNREACHABLE.

• quand un hôte ou un check revient d'un état d'erreur "HARD". C'est ce qu'on appelle une reprise "HARD".

• quand on reçoit un check passif. Les checks passifs sont traités en état "hard" .

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

• le traitement d'événements est lancé pour gérer l'état "HARD"

• les contacts sont notifiés au sujet du problème ou de sa résolution.
• Une vérification de l'état de son parent est alors forcée si ce dernier est en état non-OK et non-confirmé ( SOFT ) uniquement.

Les notations de remplacement de contenu $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. Plus d'informations disponibles dans la page des Gestionnaire d'événements.

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 ci dessous montre le résultat de vérifications consécutives sur un check, la valeur du paramètre max_check_attempts étant à 3.