Nagios – Les objets

Introduction

Dans cette section, la configuration des différents objects de Nagios va être traitée point par point avec une courte explication des principaux paramètres.

Il est considéré que Nagios est correctement configuré en suivant ce document: Configuration générale

Les commands

Dans Nagios, les commands servent à relier les plugins avec les services et les hosts que l’on souhaite vérifier.

Par exemple pour un host, on utilise une commande qui va vérifier que le host répond toujours. La commande s’appelle check-host-alive et est de la forme suivante:

 

define command{
        command_name    check-host-alive
        command_line    /usr/lib/nagios/plugins/check_ping -H $HOSTADDRESS$ -w 5000,100% -c 5000,100% -p 1
        }

 

Les paramètres sont:

 

  • command_name définit le nom court de la commande que Nagios utilisera pour l’identifier.
  • command_line définit la ligne de commande que Nagios va executer. Les paramètres de la ligne de commande sont:
    • le plugin check_ping avec son chemin complet
    • -H $HOSTADDRESS$ nous permet de récuperer l’adresse de la machine à tester et de la passer en argument au plugin avec l’option -H
    • -w 5000,100% spécifie le seuil de l’état warning du check. Dans ce cas, nous serons en état warning si le host répond en plus de 5 secondes ou que l’on perd 100% des paquets.
    • -c 5000,100% spécifie le seuil de l’état critical du check. Avec les mêmes seuils que dans l’état warning. Mais dans ce cas, ce check n’est en rien fait pour vérifier la performance de liaison avec le host vérifié mais juste pour vérifier si il répond ou non.
    • -p 1 spécifie que l’on envoie un seul paquet icmp.

 

Prenons un autre exemple avec une commande qui utilise un de mes plugins SNMP:

 

define command{
        command_name    check_netsnmp_process
        command_line    /usr/lib/nagios/plugins/check_snmp_process_servers.pl -H $HOSTADDRESS$ -C $ARG1$ -w $ARG2$
        -c $ARG3$
        }

 

Les paramètres sont:

 

  • command_name nous permet de spécifier le nom court de la commande que Nagios utilisera pour l’identifier.
  • command_line définit la ligne de commande que Nagios va exécuter. Les paramètres de la ligne de commande sont:
    • check_snmp_process_servers.pl qui est le nom du plugin.
    • -H $HOSTADDRESS$ pour passer au plugin l’addresse du host à vérifier.
    • -C $ARG1$ spécifie la communauté SNMP pour interroger le host distant. Elle sera passée sur la ligne de commande au moment de déclarer le check du service. Nous verrons cela au moment de déclarer les services.
    • -w $ARG2$ spécifie le seuil de l’état warning.
    • -c $ARG3$ spécifie le seuil de l’état critical.

 

Il ne reste plus qu’à définir toutes les autres commandes dont vous aurez besoin.

La façon la plus simple de définir proprement ses commandes et d’utiliser les plugins en ligne de commande pour tester les paramètres possibles.

Les timeperiods

Les timeperiods servent à définir des plages horaires où les hosts et services seront vérifiés. Elles servent aussi pour définir les moments où Nagios envoie les notifications.

Prenons un exemple avec une timeperiod qui correspond aux horaires de travail sur une semaine:

 

define timeperiod{
        timeperiod_name horaires_bureau
        alias           Les horaires de bureau normaux
        monday          08:00-19:00
        tuesday         08:00-19:00
        wednesday       08:00-19:00
        thursday        08:00-19:00
        friday          08:00-19:00
        }

 

Un autre exemple avec les horaires de l’astreinte pour les nuits et les week-ends:

 

define timeperiod{
        timeperiod_name horaires_astreinte
        alias           Les horaires d'astreinte
        sunday          00:00-24:00
        monday          00:00-08:00,19:00-24:00
        tuesday         00:00-08:00,19:00-24:00
        wednesday       00:00-08:00,19:00-24:00
        thursday        00:00-08:00,19:00-24:00
        friday          00:00-08:00,19:00-24:00
        saturday        00:00-24:00
        }

 

Les paramètres sont:

 

  • timeperiod définit le nom court de la timeperiod que Nagios utilisera pour l’identifier.
  • alias est un nom plus long et plus parlant qui sert de commentaire.
  • Les différents jours de la semaine les heures de début et de fin pour le jour en question.

Les contacts

Les contacts servent principalement à définir deux choses dans Nagios:

  • qui doit être notifié selon les critères
  • qui a le droit de voir les hosts et services sur l’interface web. Cela se fait en conjonction avec une authentification Apache.

Prenons un exemple de définition de contact:

 

define contact{
        contact_name                    guillaume
        alias                           Guillaume LOHEZ
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,u,r
        service_notification_commands   notify-by-email
        host_notification_commands      host-notify-by-email
        email     moi@mondomaine.net
        pager     moi@mondomaine.net
        }

 

Les paramètres sont les suivants:

 

  • contact_name définit le nom court qui permet à Nagios de l’identifier
  • alias est le nom long où l’on peut mettre plus d’informations.
  • service_notification_period pointe vers une « timeperiod » de Nagios pendant laquelle ce contact doit être notifié pour les alertes sur les services.
  • host_notification_period remplit la même fonction mais pour les alertes sur les hosts.
  • service_notification_options définit sur quel critère d’état le contact doit être notifié. Cela correspond à:
    • w: warning, état correspondant au seuil warning
    • u: unknown, état inconnu
    • c: critical, état correspondant au seuil critical
    • r: recovery, état correspondant à un retour à la normale du service
  • host_notification_options remplit la même fonction pour les hosts. Avec les critères suivants:
    • d: down, état correspondant à une absence de réponse
    • u: unreachable, état correspondat à un host qui ne peut être joint à cause d’un host parent qui est down. Voir la définition des hosts avec leurs « parents »
    • r: recovery, état correspondant au retour à la normale du host
  • service_notification_commands pointe vers une commande définie dans Nagios qui va permettre de notifier le contact en cas d’alerte sur un service. Cette commande est définie par défaut dans Nagios. Elle utilise des macros internes de Nagios pour s’ajuster à chaque service.
  • host_notification_commands remplit le même rôle mais pour les alertes sur les hosts.
  • email définit l’adresse email du contact
  • pager définir l’adresse du pager du contact. Ce paramètre doit être rensaigné même si il ne sert pas.

 

Pour gérer l’authentification depuis l’interface web, il sera nécessaire d’utiliser une authentification Apache.

Le plus simple est d’utiliser une authenfiction avec stockage en fichier htpasswd.

Dans ce cas, pour ajouter des utilisateurs, il suffit d’utiliser la commande suivante:

 

# htpasswd2 /etc/nagios2/htpasswd.users user1
# New password: "type a very secret password"
# Re-type new password: "retype the very secret password"
# Adding password for user user1

 

L’utilisateur user1 devra donc être un contact dans Nagios et il ne verra sur l’interface web que les hosts et services dont il sera en contact.

Les contactgroups

Les contactgroups servent à faciliter l’administration de Nagios pour regrouper les contacts.

C’est les contactgroups qui seront mis comme contact au niveau des hosts et services.

Prenons un exemple de définition de contactgroup:

 

define contactgroup{
        contactgroup_name       admins
        alias                   Groupes des administrateurs
        members                 guillaume
        }

 

Les paramètres sont les suivants:

 

  • contactgroup_name définit le nom court qui permet à Nagios de l’identifier
  • alias est le nom long qui peut contenir une petite description
  • members est la liste des membres du groupe séparés par des virgules

Les hosts

Les hosts servent à définir les machines avec leur IP ou leur nom DNS. Ils servent à supporter les services pour permettre à Nagios de savoir quel service est appliqué sur quel host.

Pour définir les hosts, il est plus simple d’utiliser un template car la plupart des hosts utiliseront les mêmes paramètres.

Prenons un exemple de définition de template pour un host:

 

define host{
        name                            generic-host

        check_command                   check-host-alive
        max_check_attempts              2
        check_interval                  5
        active_checks_enabled           1
        passive_checks_enabled          0
        check_period                    24x7

        obsess_over_host                0
        check_freshness                 0
        event_handler_enabled           0
        flap_detection_enabled          0
        process_perf_data               0

        retain_status_information       1
        retain_nonstatus_information    1

        contact_groups                  admins
        notifications_enabled           1
        notification_interval           60
        notification_period             24x7
        notification_options            d,r,u

        register                        0
        }

 

Les paramètres sont les suivants:

 

  • name définit le nom court de notre template qui va permettre à Nagios de l’identifier.
  • check_command pointe vers la commande qui permet à Nagios de vérifier l’état du host
  • max_check_attempts définit le nombre maximum d’essais que va faire Nagios avant de considérer que le host a changé d’état
  • check_interval définit l’intervalle normal entre deux tests
  • active_checks_enabled active les vérifications actives de Nagios. Cela signifie que Nagios exécutera la check_command définie pour le host
  • passive_checks_enabled désactive les vérifications passives de Nagios. Les vérifications passives correspondent à des états qui sont remontés à Nagios par des scripts externes. Les résultats arrivent par le fichier de commande externe avec une syntaxe précise.
  • check_period pointe vers une timeperiod définit dans Nagios pour savoir quand ce host doit être vérifié
  • obsess_over_host désactive l’exécution de la commande OCSP de Nagios. Cette commande est principalement utilisé dans le cas où plusieurs Nagios sont configurés en monitoring distribué
  • check_freshness désactive la vérification de la « fraicheur » des résultats. Cela est utilisé dans le cas où les checks sur le host ne sont que passifs
  • event_handler_enabled désactive l’exécution du event handler correspondant au host
  • flap_detection_enabled désactive la détection des hosts qui font des « up/down » trop souvent
  • process_perf_datav désactive la gestion des éléments de performance
  • retain_status_information active la conservation de l’état des hosts au cours des redémarrages de Nagios
  • retain_nonstatus_information active la conservation des états secondaires des hosts au cours des redémarrages de Nagios. Cela inclut si on a changé les notifications ou les checks depuis l’interface web par exemple
  • contact_groups pointe vers le contactgroup de Nagios qui doit être notifié en cas d’événement sur le host
  • notifications_enabled active les notifications pour le host
  • notification_interval définit l’intervalle d’envoi des notifications
  • notification_period pointe vers la timeperiod de Nagios pendant laquelle les notifications doivent être envoyées.
  • notification_options définit les états sur lesquels Nagios doit notifier pour ce host. Les états possibles sont:
    • d: down, état correspondant à une absence de réponse
    • u: unreachable, état correspondat à un host qui ne peut être joint à cause d’un host parent qui est down. Voir la définition des hosts avec leurs « parents »
    • r: recovery, état correspondant au retour à la normale du host
  • register désactive l’enregistrement en tant que host de notre template. Ce paramètre est très important, sinon Nagios l’interprétera comme un host.

 

Maintenant que le template est définit, nous allons pouvoir l’utiliser en définissant un host:

 

define host{
        use                     generic-host

        host_name               gateway
        alias                   Router
        address                 gateway.free-4ever.net

        parents                 nagios-server
        }

 

Les paramètres sont les suivants:

 

  • use pointe vers le template que l’on souhaite utiliser pour définir notre host
  • host_name définit le nom court qui va permettre à Nagios de l’identifier
  • alias est le nom long qui peut contenir une petite description
  • address définit le nom DNS ou l’adresse IP du host
  • parents pointe vers un ou plusieurs hosts Nagios pour définir qui sont les parents de ce host. Cela sert pour la carte Nagios, pour avoir les bonnes liaisons. Et aussi pour que Nagios considère que les hosts connectés derrière un host « down » ne sont pas forcement « down », mais juste non joignable: état « unreachable ».

Les hostgroups

Les hostgroups servent à grouper les hosts dans l’interface web de Nagios.

Prenons un exemple de définition de hostgroup:

 

define hostgroup{
        hostgroup_name  routers
        alias           Routers
        members         fr-gate
        }

 

Les paramètres sont les suivants:

 

  • hostgroup_name définit le nom court qui va permettre à Nagios de l’identifier
  • alias est le nom long qui peut contenir une petite description
  • members définit la liste des hosts séparés par des virgules

Les services

Les services permettent de définir quel service sera vérifié sur quel host.

De la même facon que pour les hosts, nous allons définir un template pour les services car la plupart utiliseront les mêmes paramètres.

Prenons un exemple avec une définition de template de service:

 

define service{
        name                            generic-service

        active_checks_enabled           1
        check_period                    24x7
        normal_check_interval           5
        max_check_attempts              3
        retry_check_interval            1

        passive_checks_enabled          0

        parallelize_check               1
        is_volatile                     0

        obsess_over_service             0
        flap_detection_enabled          0
        process_perf_data               0

        event_handler_enabled           0
        check_freshness                 0

        retain_status_information       1
        retain_nonstatus_information    1

        contact_groups                  admins
        notifications_enabled           1
        notification_interval           60
        notification_period             24x7
        notification_options            w,u,c,r

        register                        0
        }

 

Les paramètres sont les suivants:

 

  • name définit le nom court de notre template qui va permettre à Nagios de l’identifier.
  • active_checks_enabled active les vérifications actives de Nagios. Cela signifie que Nagios exécutera la check_command définie pour le service
  • check_period pointe vers une timeperiod définit dans Nagios pour savoir quand ce service doit être vérifié
  • normal_check_interval définit l’interval entre deux tests quand le précedent a renvoyé le même état que l’état courant du service.
  • max_check_attempts définit le nombre maximum d’essais que va faire Nagios avant de considérer que le service a changé d’état
  • retry_check_interval définit l’interval normal entre deux tests quand le précedent a retourné un état différent de l’état courant du service.
  • passive_checks_enabled désactive les vérifications passives de Nagios. Les vérifications passives correspondent à des états qui sont remontés à Nagios par des scripts externes. Les résultats arrivent par le fichier de commande externe avec une syntaxe précise.
  • obsess_over_service désactive l’exécution de la commande OCSP de Nagios. Cette commande est principalement utilisé dans le cas où plusieurs Nagios sont configurés en monitoring distribué
  • flap_detection_enabled désactive la détection des services qui font des « up/down » trop souvent
  • process_perf_data désactive la gestion des éléments de performance
  • event_handler_enabled désactive l’exécution du event handler correspondant au service
  • check_freshness désactive la vérification de la « fraicheur » des résultats. Cela est utilisé dans le cas où les checks sur le service ne sont que passifs
  • retain_status_information active la conservation de l’état des services au cours des redémarrages de Nagios
  • retain_nonstatus_information active la conservation des états secondaires des services au cours des redémarrages de Nagios. Cela inclut si on a changé les notifications ou les checks depuis l’interface web par exemple
  • contact_groups pointe vers le contactgroup de Nagios qui doit être notifié en cas d’évenement sur le service
  • notifications_enabled active les notifications pour le service
  • notification_interval définit l’intervalle d’envoi des notifications
  • notification_period pointe vers la timeperiod de Nagios pendant laquelle les notifications doivent être envoyées.
  • notification_options définit les états sur lesquels Nagios doit notifier pour ce service. Les états possibles sont:
    • w: warning, état correspondant au seuil warning
    • u: unknown, état inconnu
    • c: critical, état correspondant au seuil critical
    • r: recovery, état correspondant à un retour à la normale du service
  • register désactive l’enregistrement en tant que service de notre template. Ce paramètre est très important, sinon Nagios l’interprétera comme un service.

 

Maintenant que notre template est définit, nous allons l’utiliser dans la définition d’un service.

Prenons un exemple avec un service qui va utiliser un de mes plugins SNMP avec la commande que l’on a définit plus haut:

 

define service{
        use                             generic-service

        host_name                       gateway
        service_description             process

        check_command                   check_snmp_process!public!1!200!300
        }

 

Les paramètres sont les suivant:

 

  • use pointe vers le template que l’on souhaite utiliser pour définir notre service
  • host_name pointe vers le ou les noms courts qui vont permettre à Nagios d’identifier sur quels hosts le service va s’appliquer
  • service_description définit dans Nagios le nom de ce service. Pour pointer vers un service sur un host dans Nagios. Il faut donc deux « pointeurs » le nom du host et le nom du service. Si on a que le nom du service, on ne sait pas sur quel host il s’applique si on a spécifié plusieurs hosts à la définition
  • check_command pointe vers la command Nagios qui doit être utilisée. Les paramètres sont séparés par des « ! ». Ils sont pris dans l’ordre pour l’exécution de la commande et ils correspondant à $ARGV1$ à $ARGV4$

Les servicegroups

Les servicegroups servent à grouper les services dans l’interface web de Nagios.

Prenons un exemple de définition de servicegroup:

 

define servicegroup{
        servicegroup_name       ping_services
        alias                   Ping Services
        members                 gateway,process,host2,service2
        }

 

Les paramètres sont les suivants:

 

  • servicegroup_name définit le nom court qui va permettre à Nagios de l’identifier
  • alias est le nom long qui peut contenir une petite description
  • members définit la liste des services séparés par des virgules. Comme cela a été dit plus haut, pour identifier un service précis dans Nagios, il faut deux pointeurs. Donc la liste est de la forme: host,service,host,service, etc

Les dependencies

Les dépendences dans Nagios servent à définir que si un service sur un host est down, il ne doit plus en vérifer un ou plusieurs autres.

Par exemple, si le service DNS est « down », cela n’est plus nécessaire d’essayer de faire des requêtes MX pour envoyer des mails.

Prenons un exemple de dependency pour un service:

 

define servicedependency{
         host_name                       gateway
         service_description             dns
         dependent_host_name             gateway
         dependent_service_description   mail
         execution_failure_criteria      w
         notification_failure_criteria   w
         }

 

Les paramètres sont les suivants:

 

  • host_name pointe vers le host qui est « master »
  • service_description pointe vers le service qui est « master »
  • dependent_host_name pointe vers le host qui est « slave »
  • dependent_service_description vers le service qui est « slave »
  • execution_failure_criteria définit que si le service « master » est en état « warning » le service « slave » ne sera plus vérifié
  • notification_failure_criteria définit que si le service « master » est en état « warning » les notifications pour le service « slave » ne seront plus envoyées

 

Il existe un mécanisme similaire pour les hosts.

Les escalations

Les escalations permettent de définir dans Nagios que si un service restent « down » trop longtemps à la troisième notification, on ne notifie plus le contact associé au service mais un autre contact.

Prenons un exemple d’escalation pour un service:

 

define serviceescalation{
    host_name              gateway
    service_description    process
    first_notification     4
    last_notification      0
    notification_interval  30
    contact_groups         managers
    }

 

Les paramètres sont les suivants:

 

  • host_name pointe vers le host qui supporte le service sur lequel on veut définir l’escalade
  • service_description pointe vers le service sur lequel on veut définir l’escalade
  • first_notification définit qu’à la quatrième notification, on utilise l’escalade
  • last_notification définit qu’à partir de la cinquième notification, on utlisera toujours l’escalade ! Si cette valeur avait été mise à dix par exemple, les notifications cinq à dix seraient envoyées à l’escalade mais à partir de la onzième, on reprend le contact normal du service.
  • notification_interval définit l’interval de notification à utiliser pour le contactgroup de l’escalade. Il peut donc être différent de l’interval de notification normal
  • contact_groups pointe vers un contactgroup qui est notifié pendant l’escalade

Application de la configuration

Après tout cela vous devriez avoir un Nagios qui fonctionne correctement…

Pour vérifer cela, la commande suivante est très pratique:

 

# nagios -v /etc/nagios2/nagios.cfg
# Nagios 2.5
# Copyright (c) 1999-2006 Ethan Galstad (http://www.nagios.org)
# Last Modified: 07-13-2006
# License: GPL
#
# Reading configuration data...
#
# Running pre-flight check on configuration data...
#
# Checking services...
#        Checked 80 services.
# Checking hosts...
#        Checked 7 hosts.
# Checking host groups...
#        Checked 6 host groups.
# Checking service groups...
#        Checked 0 service groups.
# Checking contacts...
#        Checked 4 contacts.
# Checking contact groups...
#        Checked 3 contact groups.
# Checking service escalations...
#        Checked 0 service escalations.
# Checking service dependencies...
#        Checked 84 service dependencies.
# Checking host escalations...
#        Checked 0 host escalations.
# Checking host dependencies...
#        Checked 0 host dependencies.
# Checking commands...
#        Checked 173 commands.
# Checking time periods...
#        Checked 2 time periods.
# Checking extended host info definitions...
#        Checked 0 extended host info definitions.
# Checking extended service info definitions...
#        Checked 0 extended service info definitions.
# Checking for circular paths between hosts...
# Checking for circular host and service dependencies...
# Checking global event handlers...
# Checking obsessive compulsive processor commands...
# Checking misc settings...
#
# Total Warnings: 0
# Total Errors:   0
#
# Things look okay - No serious problems were detected during the pre-flight check

 

Dans le cas où il y aurait des erreurs, Nagios est assez explicite en précisant le host ou le service en faute par exemple.

Quand on arrive à zéro erreur et avertissement, il ne reste plus qu’à redémarrer, sur une Debian:

 

# /etc/init.d/nagios2 restart

Mot de la fin

Voici donc pour Nagios dans une configuration basique pour l’instant, mais déjà bien utile !!!

Dans un futur proche… ou alors un peu moins proche, je ferais peut-être une ou deux autres docs pour des configurations plus avancées de Nagios2 comme le monitoring passif ou distribué.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s