Introduction

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

• le "statut" de l'hôte ou du check ( OK, CRITIQUE, ATTENTION ou INCONNU )
• la "Confirmation du Statut" dans lequel se trouve l'hôte ou le check :
  • Un statut est non confirmé ( SOFT ), quand il s'agit d'un statut ( CRITIQUE, ATTENTION ou INCONNU ) et que l'on n'a pas atteint le nombre de vérifications prévu pour confirmer le statut.
  • Un statut est confirmé ( HARD ),
    • si c'est un statut OK,
    • ou c'est un des statuts ( CRITIQUE, ATTENTION ou INCONNU ) et que le nombre de vérifications a été atteint.

La confirmation du statut est utilisée pour déterminer quand

• les gestionnaires d'événements sont exécutés,
• les notifications sont envoyées.

Cette page décrit les différences entre statut confirmé ( SOFT ) et non confirmé ( 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 à une interruption temporaire ( SOFT ), Shinken Enterprise permet de définir combien de fois un check ou un hôte doit être (re-)vérifié avant d'être considéré comme ayant réellement un problème ( HARD ).

Ceci est contrôlé par la propriété "Nb maximum de tentatives de confirmation du statut de l'hôte" ( clé d'import : "max_check_attempts" ).

Statut non confirmé ( SOFT )

Le statut d'un élément est non confirmé ( SOFT ) selon conditions suivantes :

• Quand le résultat de la vérification d'un check ou d'un hôte est CRITIQUE, ATTENTION ou INCONNU,
• et qu'il n'a pas encore atteint le nombre d'essais défini dans la propriété "Nb maximum de tentatives de confirmation du statut de l'hôte".
  
  

Si une commande du gestionnaire d'événement ( si configuré ) sera lancée à la réception de chaque vérification de status ( Quel que soit le statut ).

• Le gestionnaire d'événements peut être très pratique si vous essayez de régler pro-activement un problème avant que le statut soit confirmé ( HARD ).
• Les données $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront la valeur "SOFT" lorsque les gestionnaires d'événements sont exécutés, ce qui permet au script de savoir quand il est nécessaire de réaliser des actions correctrives.
  ( voir la page : Les Variables ( Remplacement dynamique de contenu - Anciennement les Macros ) )

• Plus d'informations sont disponibles sur la page Gestionnaire d'événements.

Statut confirmé  ( HARD )

Le statut d'un élément est confirmé ( HARD ) selon les conditions suivantes :

• Quand le résultat de la vérification d'un check ou d'un hôte est CRITIQUE, ATTENTION ou INCONNU, et qu'il a atteint le nombre d'essais défini dans la propriété "Nb maximum de tentatives de confirmation du statut de l'hôte",
• Quand un hôte ou check change d'un statut d'erreur à un autre statut d'erreur ( CRITIQUE, ATTENTION ou INCONNU ) et que le nombre d'essais définis par la propriété "Nb maximum de tentatives de confirmation du statut de l'hôte" est dépassé ou atteint,
• Quand le résultat de la vérification d'un check est ( CRITIQUE, ATTENTION ou INCONNU ), dans ce cas, on relance une vérification de l'hôte. Si le statut de l'hôte est bien en ( CRITIQUE ou INCONNU ) alors, on considère que le statut du check est confirmé ( HARD ),
• Quand le résultat de la vérification d'un check ou d'un hôte est OK,
• Quand on reçoit le résultat d'un check passif. Les résultats de checks passifs sont directement considérés comme confirmés ( HARD ).

Le statut d'un élément devient confirmé ( HARD ), cela entraîne les conséquences suivantes :

• Une vérification de l'état de son parent est alors forcée uniquement si le statut de ce dernier est ( CRITIQUE, ATTENTION ou INCONNU ) et non confirmé ( SOFT ).
• Les contacts sont notifiés au sujet du problème ou de sa résolution ( si l'envoie de notification est configuré ).
• La commande du gestionnaire d'événement sera lancée ( si configuré ) pour gérer la confirmation du statut ( HARD ).
  • Les notations de remplacement de contenu $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront la valeur "HARD" lorsque les 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.
    ( voir la page Les Variables ( Remplacement dynamique de contenu - Anciennement les Macros ))
  • Plus d'informations sont disponibles sur la page Gestionnaire d'événements.

Exemple

Voici un exemple de la confirmation de statut ( 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.