| 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, 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é 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 ( 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".
Le statut n'est pas confirmé ( SOFT ).
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 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.
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é.
- Quand le résultat de la vérification d'un check est ( CRITIQUE, ATTENTION ou INCONNU ), dans se cas on relance une vérification de l'hôte. Si le statut de l'hôte 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 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 :
- 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 ( 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é.
- 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.
| Temps | Nombre de vérifications | Statut | Statut confirmé | Changement | Notes |
|---|---|---|---|---|---|
| 0 | 1 | OK | Oui ( HARD ) | Non | État Initial |
| 1 | 1 | CRITIQUE | Non ( SOFT ) | Oui | 1ère détection d'un statut "non OK".
|
| 2 | 2 | AVERTISSEMENT | Non ( SOFT ) | Oui | Le check continue d'être en "non OK".
|
| 3 | 3 | CRITIQUE | Oui ( HARD ) | Oui | Le nombre maximum d'essais est atteint donc l'état passe à "HARD".
|
| 4 | 1 | AVERTISSEMENT | Oui ( HARD ) | Oui | Le check passe au statut AVERTISSEMENT en état HARD.
|
| 5 | 1 | AVERTISSEMENT | Oui ( HARD ) | Non | Le check se stabilise sur un statut "non OK" en état HARD.
|
| 6 | 1 | OK | Oui ( HARD ) | Oui | Le check repasse au statut OK en état HARD .
|
| 7 | 1 | OK | Oui ( HARD ) | Non | Le check est toujours OK. |
| 8 | 1 | INCONNU | Non ( SOFT ) | Oui | Le check est détecté comme passant sur un statut "non OK" en état SOFT .
|
| 9 | 2 | OK | Oui ( HARD ) | Oui | Le check revient à un statut OK depuis un état SOFT ( reprise SOFT ) .
|
| 10 | 1 | OK | Oui ( HARD ) | Non | Le check se stabilise en état OK. |