Intégration de UCD-SNMP (NET-SNMP)

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…

Introduction

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.

Logiciels complémentaires

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®.

Définition du service

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).

Configuration SNMP d'ArcServe et de Novell

Pour qu'ArcServe (et mon serveur Novell) envoient des interruptions SNMP à mon hôte d'administration, j'ai dû mener les actions suivantes :

  1. Modifier le travail autopilot d'ArcServe pour qu'il envoie des interruptions SNMP en cas d'échec, de réussite, etc. des travaux
  2. Editer SYS:\ETC\TRAPTARG.CFG et y ajouter l'adresse IP de mon hôte d'administration (celui qui reçoit les interruptions SNMP)
  3. Charger SNMP.NLM
  4. Charger ALERT.NLM pour permettre l'envoi effectif des interruptions SNMP

Configuration de l'hôte d'administration SNMP

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 :

  1. Installer les MIB ArcServe (comprises dans le CD d'installation d'ArcServe).
  2. Editer le fichier de configuration de snmptrapd (/etc/snmp/snmptrapd.conf) pour définir un gestionnaire d'interruption [NdT : trap handler] pour les alertes ArcServe. Le détail est ci-dessous.
  3. Démarrer le service snmptrapd pour recevoir les interruptions SNMP entrantes.

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

Pour terminer

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.