Note : Nagios® n'a pas été conçu pour remplacer une application complète d'administration SNMP comme HP OpenView ou OpenNMS [Anglais]. Toutefois, vous pouvez faire en sorte que les interruptions [NdT : traps] SNMP reçus par un hôte de votre réseau génèrent des alertes dans Nagios®. Voici comment…
Cet exemple explique comment générer facilement dans Nagios® des alertes qui correspondent à des interruptions SNMP reçues par le service UCD-SNMP [Anglais] snmptrapd. Ces indications présupposent que l'hôte qui reçoit les interruptions SNMP n'est pas celui sur lequel s'exécute Nagios®. Si votre machine de supervision est la même que celle qui reçoit les interruptions SNMP, vous devrez adapter les exemples que je fournis. De plus, je présuppose que vous avez installé le service nsca sur votre machine de supervision et le client nsca (send_nsca) sur la machine qui reçoit les interruptions SNMP.
Dans cet exemple, je décrirai comment configurer Nagios® pour générer des alertes à partir des interruptions SNMP reçues concernant les travaux de sauvegarde ArcServe qui tournent sur mes serveurs Novell. Je voulais être notifié en cas d'erreur de la sauvegarde, ce qui a très bien fonctionné pour moi. Vous devrez adapter les exemples à vos propres besoins.
Traduire des interruptions SNMP en événements Nagios® peut être fastidieux. Si vous voulez vous simplifier les choses, intéressez-vous au projet SNMP Trap Translator d'Alex Burger disponible sur http://www.snmptt.org [Anglais] qui, combiné à Net-SNMP, constitue un système d'administration des interruptions plus évolué. La documentation de snmptt détaille la procédure d'intégration à Nagios®.
Vous devez d'abord définir un service dans votre fichier de configuration des objets, pour les interruptions SNMP (dans notre exemple, je définis un service pour les travaux de sauvegarde ArcServe). Si l'on suppose que l'hôte dont proviennent les alertes s'appelle novellserver, la définition du service ressemblerait à ceci :
define service{
host_name novellserver
service_description ArcServe Backup
is_volatile 1
active_checks_enabled 0
passive_checks_enabled 1
max_check_attempts 1
contact_groups novell-backup-admins
notification_interval 120
notification_period 24x7
notification_options w,u,c,r
check_command check_none
}
Il est important de noter que le paramètre volatile est activé pour ce service. Nous l'activons car nous voulons qu'une notification soit générée pour chaque alerte reçue. Notez également que les contrôles actifs sont désactivés pour ce service, et les contrôles passifs activés. Cela signifie que le service ne sera jamais contrôlé activement - toutes les informations d'alerte devront être envoyées passivement par le client nsca qui s'exécute sur l'hôte d'administration SNMP (dans mon exemple, celui-ci s'appelle firestorm).
Pour qu'ArcServe (et mon serveur Novell) envoient des interruptions SNMP à mon hôte d'administration, j'ai dû mener les actions suivantes :
Sur mon hôte Linux d'administration SNMP (firestorm), j'ai installé le logiciel UCD-SNMP [Anglais] (NET-SNMP). Une fois le logiciel installé, il m'a fallu :
Pour que le service snmptrapd route les interruptions SNMP d'ArcServe à notre hôte Nagios®, nous devons définir un gestionnaire d'interruption dans le fichier /etc/snmp/snmptrapd.conf. Dans mon cas, le fichier de configuration ressemble à ceci :
############################# # ArcServe SNMP Traps ############################# # Tape format failures traphandle ARCserve-Alarm-MIB::arcServetrap9 /usr/local/nagios/libexec/eventhandlers/handle-arcserve-trap 9 # Failure to read tape header traphandle ARCserve-Alarm-MIB::arcServetrap10 /usr/local/nagios/libexec/eventhandlers/handle-arcserve-trap 10 # Failure to position tape traphandle ARCserve-Alarm-MIB::arcServetrap11 /usr/local/nagios/libexec/eventhandlers/handle-arcserve-trap 11 # Cancelled jobs traphandle ARCserve-Alarm-MIB::arcServetrap12 /usr/local/nagios/libexec/eventhandlers/handle-arcserve-trap 12 # Successful jobs traphandle ARCserve-Alarm-MIB::arcServetrap13 /usr/local/nagios/libexec/eventhandlers/handle-arcserve-trap 13 # Imcomplete jobs traphandle ARCserve-Alarm-MIB::arcServetrap14 /usr/local/nagios/libexec/eventhandlers/handle-arcserve-trap 14 # Job failures traphandle ARCserve-Alarm-MIB::arcServetrap15 /usr/local/nagios/libexec/eventhandlers/handle-arcserve-trap 15
Cet exemple présuppose que vous avez un répertoire /usr/local/nagios/libexec/eventhandlers/ sur votre hôte d'administration SNMP et que le script handle-arcserve-trap s'y trouve. Vous pouvez modifier ces paramètres selon vos besoins. Quoiqu'il en soit, le script handle-arcserve-trap de mon hôte d'administration ressemble à ceci :
#!/bin/sh
# Arguments:
# $1 = trap type
# First line passed from snmptrapd is FQDN of host that sent the trap
read host
# Given a FQDN, get the short name of the host as it is setup in Nagios®
hostname="unknown"
case $host in
novellserver.mylocaldomain.com)
hostname="novellserver"
;;
nt.mylocaldomain.com)
hostname="ntserver"
;;
esac
# Get severity level (OK, WARNING, UNKNOWN, or CRITICAL) and plugin output based on trape type
state=-1
output="No output"
case "$1" in
# failed to format tape - critical
11)
output="Critical: Failed to format tape"
state=2
;;
# failed to read tape header - critical
10)
output="Critical: Failed to read tape header"
state=2
;;
# failed to position tape - critical
11)
output="Critical: Failed to position tape"
state=2
;;
# backup cancelled - warning
12)
output="Warning: ArcServe backup operation cancelled"
state=1
;;
# backup success - ok
13)
output="Ok: ArcServe backup operation successful"
state=0
;;
# backup incomplete - warning
14)
output="Warning: ArcServe backup operation incomplete"
state=1
;;
# backup failure - critical
15)
output="Critical: ArcServe backup operation failed"
state=2
;;
esac
# Submit passive check result to monitoring host
/usr/local/nagios/libexec/eventhandlers/submit_check_result $hostname "ArcServe Backup" $state "$output"
exit 0
Notez que le script handle-arcserve-trap appelle le script submit_check_result pour envoyer effectivement l'alerte à l'hôte de supervision. Si votre hôte de supervision s'appelle monitor, le script submit_check_result ressemblerait à ceci (modifiez-le pour préciser l'emplacement correct du programme send_nsca sur votre hôte d'administration):
#!/bin/sh # Arguments # $1 = name of host in service definition # $2 = name/description of service in service definition # $3 = return code # $4 = output /bin/echo -e "$1\t$2\t$3\t$4\n" | /usr/local/nagios/bin/send_nsca monitor -c /usr/local/nagios/etc/send_nsca.cfg
Vous avez maintenant configuré tout ce qui doit l'être, il ne reste plus qu'à redémarrer Nagios® sur votre serveur de supervision. C'est fini ! Vous devriez recevoir des alertes dans Nagios® à chaque fois qu'un travail échoue, réussit, etc.