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.
Hier bei credativ setzen wir bevorzugt Nagios für das Monitoring ein, aber wenn es die Richtilinien bei Kunden verlangen, arbeiten wir natürlich auch mit anderen
Überwachungs-Systemen. Dieses Howto beschreibt die Integration von aktiven und
passiven Nagios-Checks in ein OpenNMS-System, so dass zwar die entwickelten Checks weiter verwendet, der Nagios-Server aber abgeschaltet werden kann.
