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.
Einleitung
OpenNMS ist ein Open-Source Netzwerk-Monitoring-System. Es ist in Java
geschrieben und benutzt PostgreSQL als Datenbank. Die Konfiguration erfolgt
über XML-Dateien, teilweise (vor allem Reports, Benachrichtigungen usw.) auch
über die Web-Oberfläche. OpenNMS ist relativ stark auf SNMP fokussiert, vor
allem was das Sammeln von Performance-Daten angeht. Ob Rechner (oder Dienste
auf Rechnern) erreichbar sind, kann jedoch auch einfach anderweitig abgefragt
werden.
Dieses Howto behandelt die Migration eines Netzwerk-Überwachungs-Systems von
Nagios/
Icinga zu OpenNMS. Für aktive Nagios-Checks beruht diese Migration auf dem
NRPE Plugin (Nagios Remote Plugin Executor), welches von der stabilen
OpenNMS-Version bereits unterstützt wird. Es erfordert also ein bereits
vorhandenes NRPE-Setup für Nagios, bzw. eine Migration des Nagios-Setups zu
NRPE. Passive Nagios-Checks via NSCA (Nagios Service Check Acceptor) werden
durch SNMP-Traps in OpenNMS integriert und bedürfen keiner Änderung auf der
Nagios-Seite, lediglich das
send_nsca-Skript muss zentral ausgetauscht werden.
Die Sammlung und Bearbeitung von Performance-Daten ist mit diesem Howto
nicht möglich, hierfür wäre eine Erweiterung der OpenNMS Code-Basis nötig.
Aktive Nagios-Checks
Die aktiven NRPE-Checks werden durch den OpenNMS Service
pollerd
ersetzt. Dieser stellt das Modul
NrpeMonitor zur Verfügung, welches im
Prinzip dazu gedacht ist, einen NRPE-Service auf einem der bekannten Rechner zu
überwachen. Dazu wird alle 5 Minuten (dieser Wert ist für jeden Dienst einzeln
konfigurierbar) versucht, den NRPE-Dämon zu erreichen, wobei im Normalfall der
Befehl „
_NRPE“ abgefragt wird, welcher vom NRPE-Dämon als
Spezialfall aufgefasst wird und bei normalen Betrieb ein „
OK“
und die Versionsnummer von NRPE zurück liefert.
Alternativ kann jedoch in der Konfigurations-Datei des pollerd ein beliebiges
Kommando für den NRPE-Dämon eingestellt werden, z. B.
check_load. Wenn
dieses Kommando dem NRPE-Dämon bekannt ist, wird es ausgeführt und liefert den
üblichen Nagios-Status zurück (
OK mit Rückgabewert 0,
WARNING
mit Rückgabewert 1,
CRITICAL mit Rückgabewert 2 oder
UNKNOWN
mit Rückgabewert 3) sowie die Performance-Daten, welche jedoch momentan vom
pollerd bzw. OpenNMS nicht ausgewertet werden.
Um die bestehenden Nagios-Checks in OpenNMS abzubilden, wird für jeden bisher verwendeten aktiven Nagios-Check ein NRPE-Service in OpenNMS definiert. Diese werden dann unabhängig voneinander in OpenNMS geführt. Hierfür sind zwei Konfigurations-Dateien von OpenNMS zu ändern:
- Die Datei capsd-configuration.xml bestimmt, auf welche Dienste ein
Rechner vom OpenNMS Service capsd beim Scannen untersucht werden soll.
- Die Datei poller-configuration.xml bestimmt, welche bzw. in
welcher Art die vom capsd gefundenen Dienste vom pollerd
überwacht werden sollen.
Aus Sicherheitsgründen sollten dem NRPE-Dämon keine variablen Parameter
übergeben werden; die Abfrage des gleichen Checks mit verschiedenen Parametern
oder Schwellen-Werten sollte also als jeweils unterschiedliche Checks in NRPE
definiert werden.
Anpassung der capsd Konfiguration
Für jeden NRPE-Check muss ein neuer protocol-plugin Abschnitt in
capsd-configuration.xml definiert werden. Der
class-name ist
dabei stets
org.opennms.netmgt.capsd.plugins.NrpePlugin, normalerweise
müssen lediglich die Werte für protocol und der für das Attribut
„
command“ angepasst werden. Ein Beispiel wäre:
<protocol-plugin
protocol="NRPE-load"
class-name="org.opennms.netmgt.capsd.plugins.NrpePlugin"
scan="on">
<property key="banner" value="*" />
<property key="port" value="5666" />
<property key="timeout" value="3000" />
<property key="retry" value="2" />
<property key="command" value="check_load" />
</protocol-plugin>
Der Wert für „
protocol“ bezeichnet den Dienst, wie er intern
bzw. im Web-Interface von OpenNMS geführt werden soll. Das Attribut
„
port“ bezeichnet den Port, auf dem der NRPE-Dämon zu erreichen
ist, der Standard hierfür ist 5666. Das Attribut „
command“
bezeichnet den vom NRPE-Dämon auszuführenden Check, wie er in
/etc/nagios/nrpe.cfg (oder evtl.
/etc/nagios/nrpe_local.cfg)
definiert ist. In diesem Fall wird der übliche Nagios-Check
„
check_load“ für die Überprüfung der System-Auslastung in Bezug
auf die Anzahl der laufenden Prozesse ausgeführt.
Zu beachten ist hierbei, dass OpenNMS vor Version 1.6.9 nicht genauer den
Rückgabewert prüft und im Falle eines Checks, der nicht ein „
OK“
(sondern vorübergehend ein „
WARNING“ oder
„
CRITICAL“) zurück gibt den jeweiligen Check nicht erkennt.
Hierfür wurde von uns ein Patch entwickelt, welcher ab Version 1.6.9 in OpenNMS
enthalten ist. Falls eine frühere Version von OpenNMS eingesetzt wird, kann das
Problem durch eine temporäre Anpassung der Schwellen-Werte in der
NRPE-Konfigurations-Datei auf dem jeweiligen Rechner behoben werden, so dass
zum Zeitpunkt der Erkennung NRPE den Dienst als „
OK“ ansieht.
Falls in einem großen Rechner-Netzwerk eine Prüfung auf eine potentiell große
Anzahl von NRPE-Checks nicht im allgemeinen erwünscht ist, können diese auch
auf ein einzelnes Netzwerk-Segment oder einen IP-Bereich beschränkt werden.
Dazu wird die Beispiel-Konfiguration in einen protocol-configuration Abschnitt
eingebettet:
<protocol-plugin
protocol="NRPE-load"
class-name="org.opennms.netmgt.capsd.plugins.NrpePlugin"
scan="off">
<protocol-configuration scan="on" user-defined="false">
<range begin="192.168.178.0" end="192.168.178.254"/>
<specific>10.0.0.2</specific>
<specific>10.0.0.7</specific>
<property key="banner" value="*" />
<property key="port" value="5666" />
<property key="timeout" value="3000" />
<property key="retry" value="2" />
<property key="command" value="check_load" />
</protocol-configuration>
</protocol-plugin>
Wichtig ist hierbei der Tag
<range begin=“$IP_ADRESSE“
end=“$IP_ADRESSE“/>, welcher den IP-Bereich definiert.
Alternativ können auch über
<specific>$IP_ADRESSE</specific> Tags bestimmte
IP-Adressen festgelegt werden. Durch die Option
scan=
“off“ in der ersten Zeile wird auf allen anderen Rechnern
nicht auf diesen Check geprüft.
Nach der Änderung von
capsd-configuration.xml ist ein Neustart von
OpenNMS nötig; alternativ (ein OpenNMS-Neustart kann je nach Größe des überwachten Netzwerks eine längere Zeit dauern) kann der
capsd-Daemon per JMX RPC neu gestartet werden:
for i in stop init start; do
wget --proxy=off -O /dev/null \
"http://manager:manager@localhost:8181/invoke?objectname=OpenNMS%3AName%3DCapsd&operation=$i";
done
Wenn die Änderung hauptsächlich für einen bestimmten Rechner veranlasst wurde
und sofort aktiv sein soll, muss für diesen Rechner ein „Rescan“
ausgeführt werden; entweder per Web-Interface oder mit Hilfe des
send-event.pl Skripts, welches das entsprechende Event
(
forceRescan) an OpenNMS (auf localhost laufend) übermittelt:
send-event.pl uei.opennms.org/internal/capsd/forceRescan localhost --interface 10.0.0.2
Anpassung der pollerd Konfiguration
Die Konfigurations-Datei für den
pollerd-Service muss für jeden
NRPE-Check an zwei Stellen geändert werden; zum einen muss ein
<service> Absatz hinzugefügt werden, in dem der zu überwachende
Service ähnlich wie in der capsd-Konfigurationsdatei definiert wird, außerdem
muss eine
<monitor service=[...]/> Zeile eingefügt werden um die
Überwachung des jeweiligen Services zu aktivieren. Analog zu dem Beispiel im
letzten Abschnitt wäre dies etwa folgendes:
<service name="NRPE-load"
interval="300000"
user-defined="false"
status="on">
<parameter key="retry" value="3" />
<parameter key="timeout" value="3000" />
<parameter key="port" value="5666" />
<parameter key="command" value="check_load" />
<parameter key="padding" value="2" />
</service>
Jeweils zu ändern sind auch hier die Angaben für „
service name“
und der Parameter „
command“. Die Option
„
interval“ gibt das Überwachungs-Intervall in Millisekunden an,
der Standard-Wert ist hier üblicherweise 300000, was 5 Minuten entspricht. Die
entsprechende Zeile für die Aktivierung des
NrpeMonitor ist
<monitor service="NRPE-load"
class-name="org.opennms.netmgt.poller.monitors.NrpeMonitor"
/>
Auch beim Ändern der Datei
poller-configuration.xml ist ein Neustart
von OpenNMS nötig, bzw. ein analoger Aufruf der RPCs wie im letzten Abschnitt,
mit
Pollerd statt
Capsd als Argument:
for i in stop init start; do
wget --proxy=off -O /dev/null \
"http://manager:manager@localhost:8181/invoke?objectname=OpenNMS%3AName%3DPollerd&operation=$i";
done
Im demnächst folgenden zweiten Teil dieses Howtos wird die Integration von passiven Nagios-Checks behandelt.
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.
