Durées et fréquences des checks Nagios

Date: 23/10/2008 | Catégories: Open-source,Reseau,Systeme | Tags:

nagios_logo.pngPour 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.

nagios-check.jpg
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.

  • Hwd

    Merci pour cet article.

    Je me pose encore quelques questions au sujet de Nagios et le temps, surtout au niveau de la latence des checks.

    Peut-on paramètrer cette latence ? Je m’explique, imaginons que je dois monitorer une application web et que celle-ci met 10s pour se charger entièrement, comment spécifier à Nagios que si le site ne répond pas avant 15s, il doit nous renvoyer un CRITICAL, mais pas avant ?

    Merci encore pour ton blog qui je consulte régulièrement !

  • @Hwd: La commande check_http permet de fixer les temps de réponses « warning » (option -w) et « critical » (option -c) de ton site Web. Il te siffit donc de crer une nouvelle commande exploitant ces options et de les intégrer dans ta configuration de Nagios.

    http://blog.nicolargo.com/2008/07/exemples-de-check-de-services-nagios.html

    A+

  • Hwd

    Le problème c’est que j’utilise des scripts Homemade qui vérifie si une chaine de caractère est bien présente sur le page (grâce au script libwww en PERL)

    Tu as une idée ?

    Merci 🙂

  • medlinux

    comment peut on être sûr que le timeperiod marche
    parce que je vient de suivre ton exemple mais ça marche pas ?

    Merci de me repondre.

  • badr

    Bonjour,
    je viens de suivre le tuto mais malheuresement quand nagios detecte un équipement down il envoie pas une notification sur le coup .merci de m’indiquer le fichier de contacte.cfg doit resembler à quoi?
    cordialement.

  • Pingback: Projet : Installation et configuration d’un outil de supervision : Nagios | Portfolio |()