Introduction

L'état courant des services et des hôtes est déterminé par deux composants : l'état du service ou de l'hôte (c.a.d OK, WARNING, UP, DOWN, etc) et le type d'état dans lequel il se trouve. Il y a deux types d'état dans Nagios - les états "soft" et les états "hard". Les types d'état sont une partie cruciale de la logique de supervision de Nagios. Ils sont utilisés pour déterminer quand les gestionnaires d'événement sont exécutés et quand les notifications sont envoyées.

Réessais de contrôle de service et d'hôte

Pour éviter les alarmes indésirables, Nagios vous permet de définir combien de fois un contrôle de service ou d'hôte sera retenté avant que le service ou l'hôte soit considéré comme ayant réellement un problème. Le nombre maximal de ces tentatives est configuré par l'option <max_check_attempts> dans les définitions de service et d'hôte. Le numéro de la tentative de contrôle de service ou d'hôte en cours détermine le type d'état dans lequel ce dernier se trouve. Il y a quelques exceptions à cela dans l'algorithme de supervision, mais nous les ignorerons pour l'instant. Jetons un coup d'œil aux différents types d'état...

États soft

Un service ou un hôte est dans un état soft dans les situations suivantes...

• Quand un contrôle de service ou d'hôte retourne un état non-OK et qu'il n'a pas encore été (re)contrôlé autant de fois que spécifié dans l'option <max_check_attempts> de la définition du service ou de l'hôte. Appelons ça un état d'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.

Évènements d'état soft

Que se passe-t'il lorsqu'un service ou un hôte est dans un état d'erreur soft ou en rétablissement soft ?

• L'erreur ou le rétablissement soft est journalisé si vous avez activé les options de journalisation de tentatives de contrôle de service ou de journalisation de tentatives de contrôle d'hôte dans le fichier de configuration principal.
• Les gestionnaires d'événement sont exécutés (si vous en avez défini) pour traiter l'erreur ou le rétablissement soft du service ou de l'hôte. (Avant toute exécution de gestionnaire d'évènement, la macro $STATETYPE$ est mise à "SOFT").
• Nagios n'envoie pas de notifications aux contacts, car il n'y a pas (ou il n'y a pas eu) de "réel" problème avec le service ou l'hôte.

Comme vous pouvez le voir, la seule chose importante qui advienne lors d'un état soft est l'exécution des gestionnaires d'événement. L'utilisation des gestionnaires d'événement peut se révéler particulièrement utile si vous voulez tester et réparer préventivement un problème avant qu'il ne passe en état hard. Vous trouverez plus d'informations sur les gestionnaires d'évènement ici.

États hard

Les états hard surviennent pour les services dans les situations suivantes (les états hard des hôtes sont décrits plus loin)...

• Quand un contrôle de service 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 du service. C'est un état d'erreur hard.
• Quand un service se rétablit d'un état d'erreur hard. Ceci est considéré comme un rétablissement hard.
• Quand un contrôle de service retourne un état non-OK et que l'hôte correspondant est soit hors fonction [DOWN] soit inaccessible [UNREACHABLE]. C'est une exception à l'algorithme général de la supervision, mais c'est tout à fait logique. Si l'hôte n'est pas en fonction, pourquoi essayer de recontrôler le service?

Les états hard surviennent pour les hôtes 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.
• Quand un hôte se rétablit suite à un état d'erreur hard. Ceci est considéré comme un rétablissement hard.

Changements d'état hard

Avant d'expliquer ce qui se passe quand un hôte ou un service est en état hard, vous devez connaître les changements d'état hard. Les changements d'état hard surviennent quand un service ou un hôte...

• passe de l'état hard OK à l'état hard non-OK
• passe de l'état hard non-OK à l'état hard OK
• passe d'un état hard non-OK quelconque à un état hard non-OK d'un autre type (i.e. d'un état hard alerte [WARNING] à un état hard inconnu [UNKNOWN])

Évènements d'état hard

Que se passe-t'il lorsqu'un service ou un hôte est dans un état d'erreur hard ou en rétablissement hard ? Eh bien, ça dépend s'il y a eu un changement d'état hard (tel que décrit ci-dessus).

Si un changement d'état hard s'est produit et que le service ou l'hôte est dans un état non-OK, les actions suivantes sont enclenchées...

• Le problème hard du service ou de l'hôte est journalisé.
• Les gestionnaires d'évènement sont exécutés (si vous en avez défini) pour traiter le problème hard du service ou de l'hôte. (Avant toute exécution du gestionnaire d'évènement, la macro $STATETYPE$ est mise à "HARD").
• Les contacts seront notifiés du problème du service ou de l'hôte (si l'algorithme de notification le permet).

Si un changement d'état hard s'est produit et que le service ou l'hôte est dans un état OK, les actions suivantes sont enclenchées....

• Le rétablissement hard du service ou de l'hôte est journalisé.
• Les gestionnaires d'évènement sont exécutés (si vous en avez défini) pour traiter le rétablissement hard du service ou de l'hôte. (Avant toute exécution du gestionnaire d'évènement, la macro $STATETYPE$ est mise à "HARD").
• Les contacts recevront la notification du rétablissement du service ou de l'hôte (si l'algorithme de notification le permet).

Si un changement d'état hard NE S'EST PAS produit et que le service ou l'hôte est dans un état non-OK, les actions suivantes sont enclenchées...

• Les contacts seront re-notifiés du problème du service ou de l'hôte (si l'algorithme de notification le permet).

Si un changement d'état hard NE S'EST PAS produit et que le service ou l'hôte est dans un état OK, il ne se passe rien. En effet, le service ou l'hôte est dans un état OK et l'était aussi lors du dernier contrôle.