| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Introduction
L'état de supervision d'un hôte ou d'un check est déterminé par 2 deux composants :
- le "statut" de l'hôte ou du check ( OkOK, AttentionCRITIQUE, Critique, ATTENTION ou Inconnu 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.
Ce paragraphe Cette page décrit les différences entre état SOFT et état HARD 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 aux états transitoiresà une interruption temporaire ( SOFT ), Shinken Enterprise permet de définir combien de fois un service check ou un hôte doit être (re-)vérifié avant d'être considéré comme ayant réellement un réel problème ( HARD ).
Ceci est contrôlé par le paramètre la propriété "Nb maximum de tentatives de confirmation du statut de l'hôte" ( clé d'import : "max_check_attempts" dans la définition des checks et des hôtes. Il est important de comprendre comment sont (re )vérifiés les hôtes et checks afin de comprendre les différents types d'état.
Etat "SOFT"
.
Statut non confirmé ( SOFT )
Le statut d'un élément est non confirmé ( SOFT )selon L'état "SOFT" apparaît dans les conditions suivantes :
- quand Quand le résultat de la vérification d'un check ou d'un hôte n'est pas OK, et que le check est CRITIQUE, ATTENTION ou INCONNU,
- et qu'il n'a pas encore été revérifié atteint le nombre de fois d'essais défini dans le paramètre "max_check_attempts" 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 "erreur SOFT". C'est ce qu'on appelle une reprise "SOFT".
Le point suivant apparaît lorsqu'un check ou un hôte subit un changement d'état "SOFT" :
- le traitement d'événements est lancé pour gérer l'état "SOFT" .
- 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
Etat "HARD"
Statut confirmé ( HARD )
Le statut d'un élément est confirmé ( HARD )selon L'état "HARD" apparaît dans les conditions suivantes :
- quand Quand le résultat de la vérification d'un service check ou d'un hôte n'est pas OK, et que le check a déjà été revérifié le nombre de fois défini dans le paramètre "max_check_attempts" C'est ce qu'on appelle un erreur "HARD", le statut est alors confirmé.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 quand un hôte ou check passe d'un état d'erreur à un autre état statut d'erreur ( e.g. WARNING à CRITICAL ).( 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 quand le résultat de la vérification d'un check ou d'un hôte n'est pas OK et que est ( CRITIQUE, ATTENTION ou INCONNU ), dans ce 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". C'est ce qu'on appelle une 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 on reçoit le résultat d'quand on reçoit un check passif. Les résultats de checks passifs sont traités en état "hard" .
Les points suivants apparaissent lorsqu'un service ou un hôte subissent un changement d'état "HARD":
- le traitement d'événements est lancé pour gérer l'état "HARD"
- 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 les contacts sont notifiés au sujet du problème ou de sa résolution .Une vérification de ( si l'état envoie de son parent est alors forcée si ce dernier est en état non-OK et non-confirmé ( SOFT ) uniquement.
- 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
- 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.
- sur la page
Exemple
Voici un exemple de comment sont déterminés les types d'état 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ʳᵉ 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 |
son statut est confirmé ( HARD ).
|
|
|
|
|
|
| 4 | 1 |
| AVERTISSEMENT | Oui ( HARD ) | Oui | Le check passe |
au statut AVERTISSEMENT et est confirmé ( HARD ).
|
|
| 5 | 1 |
| AVERTISSEMENT | Oui ( HARD ) | Non | Le check se stabilise |
sur un statut "non OK" confirmé ( HARD ).
|
| 6 | 1 | OK | Oui ( HARD ) | Oui | Le check repasse |
au statut OK confirmé ( 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" non confirmé ( SOFT ). |
| |||||
| 9 | 2 | OK | Oui ( HARD ) | Oui | Le check revient à un |
statut OK depuis un statut non confirmé ( SOFT ).
|
|
|
|
| 10 | 1 | OK | Oui ( HARD ) | Non | Le |
statut du check devient OK confirmé ( HARD ). |