| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
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, ATTENTION, CRITIQUE,ou INCONNU )
- Le type d'état 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 :
- l'é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 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 a à une interruption temporaire ( état 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 réellement en 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" ).
État "SOFT"
L'état "SOFT" survient dans les selon conditions suivantes :
- Quand le résultat de la vérification d'un check ou d'un hôte n'est pas OK, et qu'il n'a pas encore atteint le nombre d'essai 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 statut n'est pas confirmé. - 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", le gestionnaire d'événements est lancé, 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".
- 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. ( voir la page LES VARIABLES ( Remplacement dynamique de contenu - Anciennement les MACROS ))
- Plus d'informations sont disponibles sur la page des Gestionnaire d'événements.
État "HARD"
L'état "HARD" survient dans les conditions suivantes :
- Quand le résultat de la vérification d'un service ou d'un hôte n'est pas OK, 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 d'un état d'erreur à un autre état d'erreur ( e.g. ATTENTION à CRITIQUE ) 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 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". On qualifie alors ce retour de "reprise HARD".
- 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.
Lorsqu'un service ou un hôte subissent un changement d'état "HARD", cela entraîne les conséquences conséquences suivantes :
- Le gestionnaire d'événements é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 ce dernier est en état non OK et non confirmé ( SOFT ).
Les notations de 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 des gestionnaires Gestionnaire d'événements.
Exemple
Voici un exemple sur la détermination du types type d'état ( soft SOFT ou hard 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.
| Temps | Nombre de vérifications | Statut | État | Changement | Notes |
|---|---|---|---|---|---|
| 0 | 1 | OK | HARD | Non | Etat Initial |
| 1 | 1 | CRITIQUE | SOFT | Oui | 1ère détection d'un statut "non OK".
|
| 2 | 2 | AVERTISSEMENT | SOFT | Oui | Le check continue d'être en "non OK".
|
| 3 | 3 | CRITIQUE | HARD | Oui | Le nombre maximum d'essais est atteint donc l'état passe à "HARD".
|
| 4 | 1 | AVERTISSEMENT | HARD | Oui | Le check passe au statut AVERTISSEMENT en état HARD.Exécution
|
| 5 | 1 | AVERTISSEMENT | HARD | Non | Le check se stabilise sur un statut "problèmenon OK" en état HARD.
|
| 6 | 1 | OK | HARD | Oui | Le check repasse au statut OK en en état HARD .
|
| 7 | 1 | OK | HARD | Non | Le check est check est toujours OK. |
| 8 | 1 | INCONNU | SOFT | Oui | Le check est détecté comme passant sur un statut "non OK" en état SOFT .
|
| 9 | 2 | OK | HARD | Oui | Le check revient à un statut OK depuis depuis un état SOFT ( reprise SOFT ) .
|
| 10 | 1 | OK | HARD | Non | Le check se stabilise en état OK. |