Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

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

  • le Le statut de l'hôte ou du check ( OkOKAttentionATTENTION, CritiqueCRITIQUE, ou InconnuINCONNU )
le
  • 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
    • L'
état SOFT et l'état HARD
    • état SOFT pour un statut à confirmer
    • L'état HARD pour un statut confirmé.

Ces états sont primordiaux, car ils sont utilisés pour déterminer quand les gestionnaires d'é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 ( SOFT ), 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 ( état HARD ).

Ceci est contrôlé par le paramètre la propriété "Nb maximum de tentatives de confirmation du statut de l'hôte" ( dans l'interface Configuration ) ou "max_check_attempts" ( dans la définition .cfg 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 survient dans les conditions suivantes :

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

Quand un check ou un hôte revient d'un état "

erreur

Erreur SOFT"

. C'est ce qu'on appelle une reprise "

, on le qualifie  ce changement de "reprise SOFT".

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

le traitement

, le gestionnaire d'événements est lancé

pour gérer l'état "SOFT"

, s'il a été configuré .

Le plus important lors gestionnaire 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 pour essayer de régler pro-activement proactivement un problème avant que l'état ne passe en "HARD". Les notations de remplacement de contenu

Les données $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront la valeur "SOFT" lorsque les gestionnaires d'événements sont seront exécutés, ce qui permet au script de savoir quand il est nécessaire de réaliser des actions correctrices.
Plus d'informations sont disponibles dans sur la page des Gestionnaire Gestionnaires d'événements.

Etat "HARD"

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

  • quand 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   qu'il a atteint le nombre d'essais défini dans la propriété "max_check_attempts" et que le dernier essai n'est pas OK.  C'est ce qu'on appelle un une erreur "HARD",   le statut est alors confirmé.
  • quand Quand un hôte ou check passe d'un état statut d'erreur à un autre état statut d'erreur  ( e.g. WARNING ATTENTION à CRITICAL).CRITIQUE ) alors le nombre d'essais défini par la propriété max_check_attempts est dépassé.
  • Quand quand le résultat de la vérification d'un check ou d'un hôte n'est pas OK pas OK et que l'hôte associé est dans un état DOWN ou UNREACHABLE.
  • quand Quand un hôte ou un check revient d'un état d'erreur "HARD". C'est ce qu'on appelle une "reprise "HARDHARD".
  • Quand un hôte ou un check revient d'un état d'erreur "SOFT", suite à une "reprise SOFT".
  • quand Quand on reçoit le résultat d'un check passif. Les résultats de checks passifs sont traités en état "hard" .directement considérés comme confirmés .


LorsquLes points suivants apparaissent lorsqu'un service ou un hôte subissent un changement d'état "HARD", cela entraîne les conséquences  suivantes :

  • le traitement Le gestionnaire d'événements est lancé pour gérer l'état "HARD"
  • les Les contacts sont notifiés au sujet du problème ou de sa résolution.
  • Une vérification du statut de l'état de son parent est alors forcée uniquement si ce dernier est en état non - OK et non - confirmé ( SOFT ) uniquement.


Les notations de remplacement de contenu $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ sont à contenu $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront la valeur "HARD" lorsque les événements sont exécutés ce gestionnaires d'événements seront exécutés, ce qui permet au script de savoir quand il est nécessaire de réaliser des actions correctrices.

Plus d'informations sont disponibles dans la page des Gestionnaire sur la page des  gestionnaires d'événements.

Exemple

Voici un exemple de comment sont déterminés les sur la détermination du types d'état (soft ou hard) 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.

TempsNombre de vérificationsType d'étatStatutÉtatType d'étatChangementNotes
01OKHARDNonEtat Initial
11CRITICALCRITIQUESOFTOui

1ère détection d'un état statut non - OK. Exécution du gestionnaire d'événements ( si paramétrésparamétré ).

22WARNINGAVERTISSEMENTSOFTOui

Le check continue d'être en non - OK . Exécution des du gestionnaire d'événements ( si paramétrésparamétré ).

33CRITICALCRITIQUEHARDOui

Le nombre maximum de check d'essais est atteint donc l'état passe à "HARD".Exécution des  
Exécution du gestionnaire d'événements ( si paramétrésparamétré )   et envoi d'une notification sur un problème. 
Une vérification du statut de l'état de son parent ( ici son hôte ) est forcée, uniquement si ce dernier est en état non - OK et non - confirmé ( SOFT ). Le nombre de vérification vérifications est remis à 1 aussitôt après.

41WARNINGAVERTISSEMENTHARDOui

Le check passe au statut AVERTISSEMENT en état HARD WARNING. Exécution des du gestionnaire d'événements ( si paramétrésparamétré ) et envoi d'une notification sur un problème.

51WARNINGAVERTISSEMENTHARDNon

Le check se stabilise sur un statut "problème" en état "problème HARD" . En fonction de la définition de l'intervalle de temps entre les notifications défini pour le check, une autre notification peut être envoyée.

61OKHARDOui

Le check repasse au statut OK en état HARD . Exécution des du gestionnaire d'événements ( si paramétrésparamétré ) et envoi d'une notification de reprise

71OKHARDNon

Le check est toujours OK.

81UNKNOWNINCONNUSOFTOui

Le check est détecté comme passant de l'état "SOFT" à "non-OK" . Exécution des sur un statut "non OK" en état SOFT . Exécution du gestionnaire d'événements ( si paramétrésparamétré ).

92OKHARDOui

Le check revient à un statut OK depuis un état SOFT ( reprise SOFT ) . Exécution des du gestionnaire d'événements ( si paramétrésparamétré ), mais pas d'envoi de notifications, car il ne s'agissait pas vraiment d'un problème. L'état est passé à "HARD" et le nombre de vérification vérifications repasse à 1 aussitôt après. 

101OKHARDNon

Le check se stabilise en état OK