Table des matières
L'état courant d'un service ou d'un hôte supervisé est déterminé par deux composants :
L'état du service ou de l'hôte (ex: OK, WARNING, UP, DOWN, etc.)
Le type d'état dans lequel l'hôte ou le service se trouve
Il y a deux types d'états dans Nagios - les états SOFT et les états HARD. Ces types d'états sont un élément crucial de la logique de supervision, ils sont utilisés pour déterminer quand les gestionnaires d'événements sont exécutés et quand les notifications sont initialement envoyées.
Ce document décrit les différences qu'il existe entre les états SOFT et HARD, comment ils surviennent, et ce qu'il se passe lorsqu'ils ont lieu.
Afin de prévenir des fausses alarmes dues à des problèmes transitoires, Nagios vous permet de définir combien de fois un service ou un hôte devra être (re)contrôlé avant d'être considéré comme ayant un réel problème. Ceci est contrôlé par l'option max_check_attempts des définitions d'hôtes et de services. Comprendre comment les hôtes et les services sont (re)contrôlés afin de déterminer si un réel problème existe est important dans la compréhension de comment les type d'états fonctionnent.
Les états SOFT surviennent dans les situations suivantes:
Quand le contrôle d'un service ou d'un hôte retournre un état non-OK ou non-UP et quand le service n'a pas été (re)contrôlé le nombre de fois spécifié par le paramètre max_check_attempts des définitions des hôtes ou des services. C'est ce qu'on appelle une erreur SOFT.
Quand un service ou un hôte se rétablit suite à un état d'erreur SOFT. Ceci est considéré comme un rétablissement SOFT.
Les choses suivantes se produisent lorsque des hôtes ou des services rencontrent des changements d'état SOFT :
L'état SOFT est journalisé.
Les gestionnaires d'événements sont exécutés pour traiter l'état SOFT.
Les états SOFT sont seulement journalisés si vous avez activé les options log_service_retries ou log_host_retries dans le fichier de configuration principal.
La seule chose importante qui se passe réellement lors d'un état SOFT, c'est l'exécution des gestionnaires d'événements. L'utilisation des gestionaires d'événements peut être particulièrement utile si vous voulez essayer et résoudre un problème de façon proactive avant qu'il ne se transforme en état HARD. Les macros $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront alors la valeur SOFT quand les gestionnaires d'événement seront exécutés, ce qui permettra aux gestionnaires d'événements de savoir quand ils devront prendre des mesures correctives. Plus d'informations sur les gestionnaires d'événements sont disponibles ici.
Les états HARD surviennent pour les hôtes et les services dans les situations suivantes:
Quand un contrôle d'hôte retourne un état non-OK et qu'il a été (re)contrôlé autant de fois que spécifié par l'option max_check_attempts de la définition de l'hôte. C'est un état d'erreur HARD.
Lorsqu'un hôte ou un service passe d'un état HARD à un autre état (ex: WARNING vers CRITICAL).
Lorsqu'un contrôle de service revoie un état non-OK et que son hôte correspondant est soit DOWN ou UNREACHABLE.
Lorsqu'un hôte ou un service redevient OK après un état non-OK HARD. Ceci est considéré comme un retour à la normale HARD
Lorsqu'un contrôle passif d'un hôte est reçu. Les contrôles passifs des hôtes sont traités comme HARD sauf si l'option passive_host_checks_are_soft est activée.
Les choses suivantes se produisent lorsque des hôtes ou des services rencontrent des changements d'état HARD:
L'état HARD est journalisé
Les gestionnaires d'événements sont exécutés pour traiter l'état HARD.
Les contacts sont notifiés d'un problème ou d'un retour à la normale d'un hôte ou d'un service.
Les macros $HOSTSTATETYPE$ ou $SERVICESTATETYPE$ auront la valeur HARD quand les gestionnaires d'événement seront exécutés, ce qui permettra aux gestionnaires d'événement de savoir qu'ils doivent effectuer une action corrective. Plus d'informations sur les gestionnaires d'événement peuvent être trouvées ici.
Voici un exemple de comment sont déterminés les types d'état, quand les changement d'états surviennent, et quand les gestionnaires d'événements sont exécutés et les notifications sont envoyées. Le tableau ci-dessous montre les contrôles consécutifs dans le temps. Le max_check_attempt du service contrôlé est positionné à 3.
|
Echelle de temps |
Contrôle # |
Etat |
Type d'état |
Changement d'état |
Notes |
|---|---|---|---|---|---|
|
0 |
1 |
OK |
HARD |
Non |
Etat initial du service |
|
1 |
1 |
CRITICAL |
SOFT |
Oui |
Première détection d'un état non-OK. Le gestionnaire d'événement s'exécute. |
|
2 |
2 |
WARNING |
SOFT |
Oui |
Le service continue d'être dans un état non-OK. Le gestionnaire d'événement s'exécute. |
|
3 |
3 |
CRITICAL |
HARD |
Oui |
Le nombre maximum de tentatives a été atteint, le service passe dans un état HARD. Le gestionnaire d'événement s'exécute et une notification est envoyée. Le compteur de tentavive repasse immédiatement à 1. |
|
4 |
1 |
WARNING |
HARD |
Oui |
Le service passe à un état WARNING HARD. Le gestionnaire d'événement s'exécute et une notifiaction du problème est envoyée. |
|
5 |
1 |
WARNING |
HARD |
Non |
Le service se stabilise dans un état HARD. Selon l'intervalle de notification spécifié pour le service, d'autres notivications peuvent être envoyées. |
|
6 |
1 |
OK |
HARD |
Oui |
Le service passe à un état OK HARD. Le gestionnaire d'événement s'exécute et une notification de retour à la normale est envoyée. |
|
7 |
1 |
OK |
HARD |
Non |
Le service est toujours OK. |
|
8 |
1 |
UNKNOWN |
SOFT |
Oui |
Le service est détecté comme ayant basculé vers un état SOFT non-OK. Le gestionnaire d'événement s'exécute. |
|
9 |
2 |
OK |
SOFT |
Oui |
Le service passe à un état de retour à la normale SOFT. Le gestionnaire d'événement s'exécute, mais aucune notification n'est envoyée, comme ce n'est pas un réel problème. Le type d'état est positionné à HARD et le compteur de tentative est positionné à 1 immédiatement après. |
|
10 |
1 |
OK |
HARD |
Non |
Service stabilisé dans un état OK. |