Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Scroll Ignore
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltrue
Panel
titleSommaire

Table of Contents
stylenone

Introduction

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

  • Le le statut de l'hôte ou du check ( OK, CRITIQUE, ATTENTION ou INCONNU)
  • Le type d'état la "Confirmation du Statut" dans lequel se trouve l'hôte ou le check , aussi appelé la "Confirmation de Statut" dans l'UI de Visualisation. Il y a deux types d'états dans Shinken Enterprise :
    • 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.

Ces états sont primordiaux, car ils sont utilisés La confirmation du statut est utilisé pour déterminer quand

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

Ce paragraphe 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  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 ( état 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 )

L'état "SOFT" survient 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 n'est pas OKest 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".
    C'est ce qu'on appelle une "Erreur SOFT", le Le statut n'est pas confirmé ( SOFT ).Quand un check ou un hôte revient d'un état "erreurSOFT", on qualifie ce changement de "repriseSOFT".
    Lorsqu'un check ou un hôte subit un changement d'état "SOFT", legestionnaire d'événements est lancé


La commande du gestionnaire d'événement sera lancée à la réception de chaque vérification d'état ( quelque soit le statut ) , s'il a été configuré.

  • Le gestionnaire 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"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 correctrices.
  • Plus d'informations sont disponibles sur la page Gestionnaire d'événements.

État "HARD"

Statut confirmé  ( HARD )

Le statut d'un élément est confirmé ( HARD )selon L'état "HARD" survient dans les conditions suivantes :

  • Quand le résultat de la vérification d'un service check ou d'un hôte n'est pas OK, 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" et que le dernier essai n'est pas OK.C'est ce qu'on appelle une erreur "HARD", le statut est alors confirmé.
  • Quand un hôte ou check passe change d'un état statut d'erreur à un autre état statut d'erreur  ( e.g. ATTENTION à CRITIQUE ( 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é.
  • Quand le résultat de la vérification d'un check est ( CRITIQUE, ATTENTION ou INCONNU ), d'un hôte n'est pas OK et que ans se cas on relance une vérification de l'hôte. Si le statut de 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". On qualifie alors ce retour de "reprise HARD".
  • est bien en ( CRITIQUEou 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 un hôte ou un check revient d'un état d'erreur "SOFT", suite à une "reprise SOFT".
  • 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 ).


Lorsqu'un service ou un hôte subissent un changement d'état "HARD"Le statut d'un élément devient confirmé ( HARD ), cela entraîne les conséquences suivantes :

Le gestionnaire 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 uniquement si le statut de ce dernier est en état non OK et non confirmé ( SOFT ).
Les notations de remplacement de contenu $
  • ( CRITIQUE, ATTENTION ou INCONNU ) et non confirmé ( SOFT ).
  • La commande du gestionnaire d'événement sera lancée pour gérer la confirmation du statut ( HARD ), s'il a été configuré.

Exemple

Voici un exemple sur la détermination du type d'état 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.

TempsNombre de vérificationsStatutStatut confirméChangementNotes
01OKOui ( HARD )NonÉtat Initial
11CRITIQUENon ( SOFT )Oui

1ère détection d'un statut "non OK".

  • Exécution du gestionnaire d'événements ( si paramétré ).
22AVERTISSEMENTNon ( SOFT )Oui

Le check continue d'être en "non OK".

  • Exécution du gestionnaire d'événements ( si paramétré ).
33CRITIQUEOui ( HARD )Oui

Le nombre maximum d'essais est atteint donc l'état passe à "HARD". 

  • Exécution du gestionnaire d'événements ( si paramétré )
  • Envoi d'une notification sur un problème. 
  • Une vérification du statut 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érifications est remis à 1 aussitôt après.
41AVERTISSEMENTOui ( HARD )Oui

Le check passe au statut AVERTISSEMENT en état HARD.

51AVERTISSEMENTOui ( HARD )Non

Le check se stabilise sur un statut "non OK" en état 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.
61OKOui ( HARD )Oui

Le check repasse au statut OK en état HARD .

  • Exécution du gestionnaire d'événements ( si paramétré )
  • Envoi d'une notification de reprise
71OKOui ( HARD )Non

Le check est toujours OK.

81INCONNUNon ( SOFT )Oui

Le check est détecté comme passant sur un statut "non OK" en état SOFT .

  • Exécution du gestionnaire d'événements ( si paramétré ).
92OKOui ( HARD )Oui

Le check revient à un statut OK depuis un état SOFT ( reprise SOFT ) .

  • Exécution du gestionnaire d'événements ( si paramé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érifications repasse à 1 aussitôt après. 
101OKOui ( HARD )Non

Le check se stabilise en état OK