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.
La version 1.4.13 des plugins officiels de Nagios viennent de sortir. Pour une description précise des changements, vous pouvez consulter ce billet sur Nagios-fr.
Petite amélioration de Sjitter, mon outil pour tester les réseaux (bande passante, délais, gigue) en ligne de commande. Le logiciel a été testé sous GNU/Linux, FreeBSD et Mac OS X.
