Nagios:configuration objets
Un article de Free-4ever.
Sommaire |
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 silencer@free-4ever.net
pager silencer@free-4ever.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é.
Par: Silencer 22 novembre 2006 à 16:51 (CET)
