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.
Wer zur alltäglichen Spamabwehr Spamassassin mit Bayes-Filter einsetzt, wird das System regelmäßig trainieren wollen. Spamassassins sa-learn benötigt als Input eine vollständige Email samt Headern und Body. Im Folgenden sei eine Methode beschreiben, wie man vollständige Emails aus Zarafa extrahieren kann.
Im Rahmen der Rubrik "Customer Stories" stellen wir unsere Kunden und die jeweils mit den Kunden verwirklichten Projekte vor. Diese Customer Story betrifft die Bayerische Landeshauptstadt München.
