Durées et fréquences des checks Nagios

Pour surveiller votre réseau, Nagios utilise un certain nombre d’objets (machines, services, contacts…). Par défaut, un objet hérite une grande partie de ses paramètres du template nommé “generic-*”. Nous allons dans ce billet nous focaliser sur les notions de temps et de fréquences de ces objets.

Pour rappel, à un instant t, un objet peut avoir un des les états suivants:

• OK: tout va bien, votre objet fonctionne correctement
• WARNING: votre objet ne fonctionne pas nominalement
• CRITICAL: votre objet ne fonctionne plus
• UNKNOWN: impossible de déterminer l’état de votre objet

Un exemple: imaginons un service qui surveille la débit de votre liaison Internet…

• OK: le débit est inférieure à 70% de la bande passante totale
• WARNING: la débit est supérieure à 70% de la bande passante totale
• CRITICAL: la liaison Internet est DOWN (plus de connectivité avec Internet)
• UNKNOWN: impossible de récupérer les valeurs du débit

Définition de la période d’activité d’un objet

La variable check_period permet de définir l’intervalle de temps durant lequel l’objet est actif. On définie une période de temps en utilisant la structure timeperiod.

Par exemple pour définir une période de temps correspondant aux heures ouvrées de votre entreprise vous pouvez utiliser la définition suivante:

define timeperiod {

timeperiod_name workhours

alias Heures ouvrées

monday 09:00-18:00 ; Lundi

tuesday 09:00-18:00; Mardi

wednesday 09:00-18:00; Mercredi

thursday 09:00-18:00; Jeudi

Friday 09:00-18:00; Vendredi

}

La déclaration de cette période de temps dans notre objet (par exemple un service) se fera ainsi:

define service {

…

check_period workhours

}

Définition des intervalles de vérification d’un objet

Quand on se trouve dans une période d’activité d’un service, plusieurs paramètres rentrent en jeu pour fixer la durée et la fréquence des vérifications (checks) du objet en question.

Quand un objet est OK, il est vérifié toutes les check_interval minutes. Si il passe WARNING, CRITICAL ou UNKNOWN, il est alors vérifié max_check_attempts fois à un intervalle de retry_interval minutes. Si l’état de l’objet n’est pas revenu à OK au bout des max_check_attempts essais, l’intervalle de vérification redevient de check_interval minutes…

Je sais ce n’est pas très simple mais ce schéma devrait vous aider à comprendre.

Un exemple de paramètrage avec un valeur de check_interval (quand tout va bien) à 10 minutes puis un retry_interval (quand cela commence à aller mal) à 2 minutes et un nombre de max_check_attempts à 3:

define service {

…

check_interval 10

retry_interval 2

max_check_attempts 3

}

Et les notifications ?

Il existe des variables permettant de fixer comment les notifications sont remontés aux administrateurs.

La première variable est first_notification_delay. Elle permet de définir le temps (en secondes) que Nagios doit attendre avant d’envoyer une notification quand un objet passe d’un état OK à un état WARNING, CRITICAL ou UNKNOWN. Une valeur de 0 permet d’envoyer la notification dès ce changement d’état.

La variable notification_interval permet, en cas de problème sur un objet, de fixer l’intervalle de temps (en minutes) entre deux notifications. Pour que Nagios n’envoie qu’une seule fois une alerte, il faut fixer cette variable à 0.

Par exemple, pour que la première notification se fasse immédiatement, sans répétition, un objet doit être défini ainsi:

define service {

…

first_notification_delay 0

notification_interval 0

}

Conclusion

Comme on vient de le voir il est relativement facile de configurer finement les fréquences et durées de vérifications en fonction de l’importance des objets à surveiller.