24 November 2010

[Howto] Nagios-OpenNMS Migration Teil 2: Passive Checks

Dies ist der zweite Teil unseres Migrations-Howtos für Netzwerk-Überwachungs-Systeme von Nagios nach OpenNMS. Nachdem im ersten Teil die Integration von aktiven Nagios-Checks via NRPE (Nagios Remote Plugin Executor) diskutiert wurde, wenden wir uns in diesem zweiten Teil den passiven Nagios-Checks durch NSCA (Nagios Service Check Acceptor) zu.

Passive Nagios-Checks

Da es momentan keine spezielle OpenNMS-Unterstützung für passive NSCA-Checks gibt, müssen diese durch andere Mechanismen abgebildet werden. In diesem Howto verwenden wir für jeden passiven NSCA-Check einen eigenen Service, dessen Status durch externe Benachrichtigung geändert wird und der durch den PassiveStatusKeeper-Mechanismus von OpenNMS überwacht wird.

Einbinden der Nagios SNMP-Trap Informationen

Für die sinnvolle Behandlung von SNMP-Traps wird eine Registrierung des jeweiligen MIBs (Management Information Base) als OpenNMS-Event benötigt. OpenNMS kennt zwar von Haus aus eine Vielzahl von SNMP-Traps, die aus dem Nagios-MIB sind jedoch nicht darunter. Die benötigte Nagios.events.xml Datei wurde aus dem MIB erstellt und muss in das events/-Unterverzeichnis der OpenNMS Konfiguration kopiert werden und in der eventconf.xml Datei via <event-file>events/Nagios.events.xml </event-file> eingebunden werden. Der in der Nagios-MIB definierte SNMP-Trap für Service-Events ist nSvcEvent, welcher als numerische OID (Object Identifier) den Code .1.3.6.1.4.1.20006.1.7 besitzt.

Benachrichtigungen via SNMP-Trap

Das für passive NSCA-Checks verwendete Programm send_nsca kann etwa durch folgendes Shell-Skript ersetzt werden, welches die Benachrichtigung von OpenNMS via snmptrap durchführt:

  #!/bin/bash
 
  SNMPTRAP=/usr/bin/snmptrap
  COMMUNITY=public
 
  while getopts "H:d:p:" OPTION; do
    case $OPTION in
      H) HOST=$OPTARG;;
      d) DELIM=$OPTARG;;
      p) PORT=$OPTARG;;
      *) ;;
    esac
  done
 
  if [ "x$DELIM" == "x" ]; then
    DELIM="\t"
  fi
 
  if [ "x$HOST" == "x" ]; then
    echo "No host defined, exiting"
    exit
  fi
 
  array=(`awk -F"$DELIM" '{for(i=1;i<=3;i++){print $i};
                    for(i=4;i<=NF;i++){gsub(/ /,"_",$i); print $i}}'`);
  NODE=${array[0]}
  SERVICE=${array[1]}
  STATUS=${array[2]}
  REASON=`echo ${array[3]} | sed s/_/\ /g`"'"
 
  $SNMPTRAP -v 2c -c $COMMUNITY $HOST '' NAGIOS-NOTIFY-MIB::nSvcEvent \
    NAGIOS-NOTIFY-MIB::nHostname s "$NODE" \
    NAGIOS-NOTIFY-MIB::nHostStateID i 0 \
    NAGIOS-NOTIFY-MIB::nSvcDesc s "$SERVICE" \
    NAGIOS-NOTIFY-MIB::nSvcStateID i "$STATUS" \
    NAGIOS-NOTIFY-MIB::nSvcAttempt i 1 \
    NAGIOS-NOTIFY-MIB::nSvcDurationSec i 1 \
    NAGIOS-NOTIFY-MIB::nSvcGroupName s "" \
    NAGIOS-NOTIFY-MIB::nSvcLastCheck i 0 \
    NAGIOS-NOTIFY-MIB::nSvcLastChange i 0 \
    NAGIOS-NOTIFY-MIB::nSvcOutput s "$REASON"

Das Skript versteht die beiden nsca_send Optionen -H (Host) und -d (Feldtrenner). $HOST ist dabei der OpenNMS-Server, für den die Benachrichtigung vorgesehen ist. Der awk-Befehl zerteilt den per Feldtrenner separierten NSCA-String (z.B. „postgres-test; Vaccuum;0;Vaccuum OK 1276511175“) in seine Bestandteile, welche den Variablen $NODE, $SERVICE, $STATUS und $REASON zugeteilt werden. Diese werden schließlich beim Aufruf von snmptrap den nSvcEvent Parametern nHostname, nSvcDesc, nSvcStateID und nSvcOutput zugeteilt. Den übrigen Parametern nHosteStateID, nSvcAttempt, nSvcDurationSec, nSvcGroupName, nSvcLastCheck und nSvcLastChange werden allgemeine Werte zugeteilt, da sie bei der Umsetzung des nSvcEvent-Traps in ein OpenNMS-Event keine Rolle spielen und auch beim Aufruf von send_nsca nicht bekannt sind. Damit die Parameter des nSvcEvent-Traps von snmptrap aufgelöst werden können, muss das NAGIOS-MIB der Net-SNMP-Installation bekannt sein.

Umwandlung von Traps in Events

Die eingehenden SNMP-Traps werden in OpenNMS-Events vom Typ nSvcEvent umgewandelt. Um diese nun einzelnen Nagios-Checks bzw. OpenNMS-Services zzuuweisen, müssen sie vom translatord-Dämon in passiveServiceStatus Events umgewandelt werden. Folgender Abschnitt ist hierfür in der Datei translator-configuration.xml nötig:

<event-translation-spec 
  uei="uei.opennms.org/vendor/nagios/traps/nSvcEvent">
    <mappings>
      <mapping>
        <assignment type="parameter" name="passiveNodeLabel">
          <value type="parameter" 
            name=".1.3.6.1.4.1.20006.1.1.1.2" 
            matches=".*" 
            result="${0}" 
          />
        </assignment>
        <assignment type="parameter" name="passiveIpAddr">
          <value type="field" 
            name="interface" 
            matches=".*" 
            result="${0}"
          />
        </assignment>
        <assignment type="parameter" name="passiveServiceName">
          <value type="parameter" 
            name=".1.3.6.1.4.1.20006.1.3.1.6" 
            matches=".*" 
            result="${0}" 
          />
        </assignment>
        <assignment type="parameter" name="passiveStatus">
          <value type="sql" 
            result="SELECT CASE WHEN ?::integer = 0  
                                     THEN 'Up'        
                                     ELSE 'Down' 
                                     END;" >  
            <value type="parameter" 
              name=".1.3.6.1.4.1.20006.1.3.1.7" 
              matches=".*" 
              result="${0}" 
            />
          </value>
        </assignment>
        <assignment type="parameter" name="passiveReasonCode">
          <value type="parameter" 
            name=".1.3.6.1.4.1.20006.1.3.1.17" 
            matches=".*" 
            result="${0}" 
          />
        </assignment>
        <assignment type="field" name="uei">
          <value type="constant" 
            result="uei.opennms.org/services/passiveServiceStatus" 
          />
        </assignment>
      </mapping>
    </mappings>
</event-translation-spec>

Die uei in der zweiten Zeile bezeichnet dabei den SNMP-Trap, wie er in der jeweiligen events-XML Datei angegeben ist. Die Parameter passiveNodeLabel, passiveServiceName, passiveStatus und passiveReasonCode werden aus den jeweiligen Parametern $NODE, $SERVICE, $STATUS und $REASON des SNMP-Traps übernommen. Für die Ermittlung von passiveStatus ist dabei eine SQL-Abfrage nötig, um je nach Nagios-Status ein „Up“ oder „Down“ zu senden. Die IP-Adresse kann direkt aus dem „interface„-Feld des Events übernommen werden. Schließlich wird in der letzten Zuordnung die OpenNMS UEI (Unique Event Identifier) von nSvcEvent nach passiveServiceStatus umgewandelt.

Einbinden von Passiven Checks als Services

Passive NSCA-Checks können naturgemäß nicht mit capsd entdeckt werden, deshalb müssen sie per LoopPlugin für jede betreffende Node per ip-match Property in der capsd-configuration.xml Datei aktiviert werden:

<protocol-plugin 
  protocol="NSCA-check1" 
  class-name="org.opennms.netmgt.capsd.plugins.LoopPlugin"
  scan="on">
  <property key="ip-match" value="192.168.178.158" />
  <property key="ip-match" value="172.16.17.213" />
  <property key="is-supported" value="true" />
</protocol-plugin>

Dabei bezeichnet protocol den Namen des betreffenen OpenNMS-Service.

Zusätzlich ist auch ein entsprechender Poller in poller-configuration.xml nötig, zum einen der <service>-Anker:

<service name="NSCA-check1" 
  interval="30000" 
  user-defined="false" 
  status="on">
</service>

Sowie schließlich ein PassiveServiceMonitor:

<monitor service="NSCA-check1" 
  class-name="org.opennms.netmgt.poller.monitors.PassiveServiceMonitor"
/>

Mit diesen Änderungen und nach einem Neustart von OpenNMS sollten die NSCA-Checks für die entsprechende Node im OpenNMS-Webinterface erscheinen und sich wie normale OpenNMS Dienste in Bezug auf Ausfälle etc. verhalten.

Kategorien: HowTos
Tags: Monitoring Nagios

über den Autor

Michael Banck

zur Person

Michael Banck ist seit 2009 Mitarbeiter der credativ GmbH, sowie seit 2001 Mitglied des Debian Projekts und auch in weiteren Open Source Projekten aktiv. Als Mitglied des Datenbank-Teams von credativ hat er in den letzten Jahren verschiedene Kunden bei der Lösung von Problemen mit und dem täglichen Betrieb von PostgreSQL<sup>®</sup>, sowie bei der Einführung von Hochverfügbarkeits-Lösungen im Bereich Datenbanken unterstützt und beraten.

Beiträge ansehen


Beitrag teilen: