sur une

- Le fichier services.cfg -

Le fichier services.cfg définit les differents services qui seront espionnés sur les Hosts. Tout comme les hosts il faut définir un service générique comme modèle auquel tous les services se rapporteront. Ces services sont déclarés dans le fichiers checkcommands.cfg. Dans ce fichier il y a déjà beaucoup de services qui sont déclarés, mais il n'y sont pas tous. Donc lorsque vous déclarez dans le fichier services.cfg un service à espionner, regardez la syntaxe de celui-ci dans le fichier checkcommands.cfg, et si celui-ci n'y apparait pas alors créez le.

Exemple de services.cfg :

# Déclaration d'un modèle de service générique qui sera utilisé plusieurs fois.
define service{
name generic-service
; Active la vérification des services actifs.
active_checks_enabled 1
; Active la vérification des services passifs.
passive_checks_enabled 1
; Il est conseillé de laisser activé ce paramètre pour des raisons de performance.
parallelize_check 1
; We should obsess over this service (if necessary)
obsess_over_service 1
; Déactive le contrôle de validité des données.
check_freshness 0
; Active le service d'avertissements.
notifications_enabled 1
; Active le gestionnaire d'évènements.
event_handler_enabled 1
; Active la détection de changement d'états.
flap_detection_enabled 1
; Process performance data
process_perf_data 1
; Retain status information across program restarts
retain_status_information 1
; Retain non-status information across program restarts
retain_nonstatus_information 1
; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
register 0
}

## Déclaration d'un service par exemple le ping (déjà référencer dans le checkcommands.cfg)

# Déclaration du service à surveiller pour l'hôte hote1 (voir fichier hosts.cfg)
define service{

; On utilise les paramètres du service générique.
use generic-service
; Nom de l'hôte.
host_name hoste1
; Description du service à surveiller.
service_description Ping du Host1
; Si le service à surveiller n'est pas important mettre à 1.
is_volatile 0
; C'est la période durant laquelle les vérifications actives de ce service
; peuvent être faites (24hx7j). Voir le fichier timeperiods.cfg
check_period 24x7
; C'est le nombre de fois que Nagios relancera la commande de contrôle du
; service si celle-ci retourne un état différent de OK.
; Positionner cette valeur à 1 fera que Nagios générera une alerte sans
; re-contrôler ce service.
max_check_attempts 3
; C'est l'intervalle écoulé en minute entre chaque vérifications standards.
normal_check_interval 5
; Pareil que l'option précédente mais pour une autre tentative.
retry_check_interval 1
; Indique le nom du groupe à contacter en cas de problèmes.
contact_groups equipements-admins
; C'est l'intervalle écoulé en minute avant d'alerter un contact quand le
; service ne répond plus ou est inaccessible. Si vous mettez cette valeur
; à 0, Nagios n'alertera pas les contacts pour ce service, une seule
; notification sera émise.
notification_interval 240
; C'est la période durant laquelle le gestionnaire d'évènements peut
; envoyer des avertissements.
notification_period 24x7
; Définit quand les avertissements pour ce service doivent être envoyés.
; Les options valides sont les suivantes :

; w = envoi de la notification pour un état WARNING

; u = envoi de la notification pour un état UNKNOWN

; c = envoi de la notification pour un état CRITICAL
; r = envoi de la notification pour un retour à la normale (état OK).

; n = (none) aucune notification ne sera envoyée.
notification_options c,r
; La commande à utiliser pour le surveiller.
check_command check_ping!100.0,20%!500.0,60%

# Les paramètres placés après la commande check_ping peuvent se trouver en tapant dans une console /usr/lib/nagios/plugins/check_ping --help
# Il est à noter que toutes les commandes sont paramètrable de cette façons. Ainsi avant de paramètrer un service dans services.cfg regardez les options disponnible dans l'aide associée à ce service.
}

## Ici un exemple utilisant le snmp et un plugins non déclaré dans checkcommands.cfg : check_disk (téléchargeable sur http://www.nagiosexchange.org/ )

define service{
use generic-service
host_name hoste1
service_description Surveille le disk C de hoste1
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups admins
notification_interval 120
notification_period 24x7
notification_options w,u,c,r
check_command check_disk!C
}

- Le fichier checkcommands.cfg -

Dans ce fichier il y a beaucoup de commandes pré-installées, je ne reviendrai pas sur celle qui existe mais en vous donnerai que l'exemple de check_disk utilisé précédement.

define command{
command_name check_disk
# il faut lui donner un nom qui sera appellé dans le fichier services.cfg. Utilisez de préfèrence un nom simple et explicite.

command_line /usr/lib/nagios/plugins/check_disk.pl $HOSTADDRESS$ $ARG1$
# command_line appelle le fichier perl, donc indiquez le chemin où Nagios le trouvera. Pour simplifier enregistrez tous les script perl dans le répertoire d'origine des script de Nagios : /usr/lib/nagios/plugins/

# l'argument $HOSTADDRESS$ renvoie la variable correspondant à host_name dans le fichier services.cfg qui lui renvoie à la déclaration du host dans le fichier hosts.cfg.
# l'argument $ARG1$ est une variable qui est appellé après la commande déclaré dans services.cfg, dans notre exemple check_disk!C le ! indique à Nagios l'entré d'une variable et C est la variable.
# Ainsi notre commande appellée dans le fichier services.cfg devient : /usr/lib/nagios/plugins/check_disk.pl 10.0.0.1 C (vous pouvez la tester en mode console et voir le résultat.
# Le nombre de variable $ARGx$ n'est pas fixe, vous pouvez passer autant de variable que vous le voullez en fonction du nombre d'options que vous fournit la commande. Vous pouvez également les passer en dur dans le fichier checkcommands mais celà est moins interessant, ainsi ici nous aurions pu définir dans services.cfg : check_disk et indiquer dans checkcommands.cfg : command_line /usr/lib/nagios/plugins/check_disk.pl $HOSTADRESS$ C. Mais dans le cas où nous aurions voulu espionner le disque D, nous aurions du ajouter une nouvelle commande à checkcommands.cfg or dans notre cas il est préférable d'ajouter un service avec la commande check_disk!D

}


Suite de la configuration