Introduction
L'état de supervision d'un hôte ou d'un check est déterminé par 2 composants :
- Le statut de l'hôte ou du check (Ok, Attention, Critique, ou Inconnu)
- 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'état SOFT pour un état à confirmer
- et l'état HARD pour un état 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 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).
Etat "SOFT"
L'état "SOFT" survient dans les 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 défini dans la propriété "max_check_attempts". C'est un statut que l'on qualifie d' "Erreur SOFT", le statut n'est pas confirmé.
Quand un check ou un hôte revient d'un état "Erreur SOFT", on le qualifie de "reprise SOFT".
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 pour essayer de régler proactivement un problème avant que l'état ne passe en "HARD".
Les notations de remplacement de contenu $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront la valeur "SOFT" lorsque les é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 disponibles dans la page des Gestionnaires d'événements.
Etat "HARD"
L'état "HARD" apparaît dans les conditions suivantes :
- Quand le résultat de la vérification d'un service ou d'un hôte n'est pas OK, et 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 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. WARNING à CRITICAL).
- 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". C'est ce qu'on appelle une "reprise " HARD".
- 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 .
Les points suivants apparaissent lorsqu'un service ou un hôte subissent un changement d'état "HARD":
- Le traitement 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 du statut de l'état de son parent est alors forcée 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 exécutés, ce qui permet au script de savoir quand il est nécessaire de réaliser des actions correctrices.
Plus d'informations disponibles dans la la page des Gestionnaire d'événements.
Exemple
Voici un exemple 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.
| Temps | Nombre de vérifications | Type d'état | Type d'état | Changement | Notes |
|---|---|---|---|---|---|
| 0 | 1 | OK | HARD | Non | Etat Initial |
| 1 | 1 | CRITIQUE | SOFT | Oui | 1ère détection d'un état statut non OK. Exécution du gestionnaire d'événements (si paramétrésparamétré). |
| 2 | 2 | AVERTISSEMENT | SOFT | Oui | Le check continue d'être en non OK . Exécution des du gestionnaire d'événements (si paramétrésparamétré). |
| 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 AVERTISSEMENT. Exécution des du gestionnaire d'événements (si paramétrésparamétré) et envoi d'une notification sur un problème. |
| 5 | 1 | AVERTISSEMENT | HARD | Non | 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. |
| 6 | 1 | OK | HARD | Oui | 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. |
| 7 | 1 | OK | HARD | Non | Le check est toujours OK. |
| 8 | 1 | INCONNU | SOFT | Oui | Le check est détecté comme passant de l'état "SOFT" à sur un statut "non OK" en état SOFT . Exécution des du gestionnaire d'événements (si paramétrésparamétré). |
| 9 | 2 | OK | HARD | Oui | 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érifications repasse à 1 aussitôt après. |
| 10 | 1 | OK | HARD | Non | Le check se stabilise en état OK . |