30. August 2010
In OpenNMS gibt es zwar auch einen “nativen” Memcached-Monitor – aber dieser funktioniert nur wenn der Memcached direkt über das Netz vom Monitorserver aus erreichbar ist.
Mit der bekannten SNMP-extend Methode lässt sich der Memcached Daemon auch gut via SNMP mit OpenNMS überwachen. Hier nur kurz die wichtigsten Scripte und Schritte:
Service überwachen
Das geht am einfachsten über das “HostResourceSwRunPlugin” Plugin welches die laufenden Prozesse via SNMP überwacht. Zunächst muss der Service überhaupt erkannt werden:
/etc/opennms/capsd-configuration.xml
<protocol -plugin protocol="Process-memcached"
class-name="org.opennms.netmgt.capsd.plugins.HostResourceSwRunPlugin"
scan="on" user-defined="false">
<property key="timeout" value="2000" />
<property key="retry" value="1" />
<property key="service-name" value="memcached" />
</protocol>Dann wird die Überwachung definiert:
/etc/opennms/poller-configuration.xml
...
<service name="Process-memcached" interval="300000"
user-defined="false" status="on">
<parameter key="retry" value="5"/>
<parameter key="timeout" value="10000"/>
<parameter key="service-name" value="memcached"/>
<parameter key="run-level" value="3"/>
<parameter key="match-all" value="true"/>
</service>
...
<monitor service="Process-memcached" class-name="org.opennms.netmgt.poller.monitors.HostResourceSwRunMonitor"/>Statistiken
Um noch ein paar Graphen zu generieren werden per SNMP noch die Statusdetails des Memcached Daemons übertragen…
Weiterlesen
8. Juni 2010
Es ist soweit: OpenNMS 1.8 ist da. Eher unbeabsichtigt kam ich soeben in die Lage unser NMS auf Version 1.8 zu hieven. Eigentlich wollte ich nur ein paar Updates einspielen und rechnete nicht damit, dass ein Major-Update darunter war 
. Glücklicherweise lief alles bis auf eine Kleinigkeit problemlos.
Da ich das OpenNMS-repository in der sources.list habe, reichte mein routinemäßig durchgeführtes “apt-get update && apt-get upgrade” um OpenNMS auf 1.8 zu bringen. Die Fragen zum Überschreiben diverser Konfigurationsdateien habe ich alle mit “N” beantwortet. Die neuen Dateien werden dann mit *.dpkg-dist angelegt. Anschließend bin ich die Änderungen manuell durchgegangen – schließlich möchte ich nichts neues verpassen und aber auch meine alten Daten weiterverwenden.
OpenNMS startete. Leider konnte ich mich nicht in das Webinterface einloggen. Irgendeine Fehlermeldung die Datenbank betreffend. Hmm, da scheint apt wohl die Datenbank nicht aktualisiert zu haben (warum eigentlich nicht?). Da ich nicht wusste was zu tun ist, bin ich nochmal den oben erwähnten Wiki-Eintrag durchgegangen. Im Abschnitt “Initialize OpenNMS and the Database” fand sich dann der unscheinbare aber wichtige Satz:
Upon upgrade, you should run this command again to make sure your database schema and other things required at startup are up-to-date
Also folgendes Kommando ausgeführt:
/usr/share/opennms/bin/install -dis
Anschließend konnte ich mich wieder einloggen. Auf dem ersten Blick scheint alles das Update überstanden zu haben. Die custom-Poller arbeiten und meine Graphen werden weiter aufgezeichnet. Jetzt schaue ich mir erst mal die neuen Features an…
3. April 2010
OpenNMS ist klasse. Man merkt an vielen Stellen, dass es von Anfang an für große Netze konzipiert wurde. Das hat den “Nachteil” dass einiges u.U. auf dem ersten Blick etwas umständlich wirkt. Ein Beispiel dafür sind z.B. die Filter. Anfangs habe ich diese nicht beachtet und diverse Parameter lieber händisch im Webinterface eingestellt oder viel mit IP-Ranges bei den Pollern gearbeitet.
Eines der Hauptprobleme war, dass OpenNMS immer alle Interfaces auf einem Server bei seinen Service-Checks einbezieht. Also z.B. den SSH-Dienst auf einem Webserver mit 30 virtuellen Interfaces auf jedem dieser Interfaces checkt. Das ist sinnlos. Beholfen habe ich mich damit, dass ich im Webinterface die ensprechenden Interfaces auf “unmanaged” gesetzt habe oder die IP-Ranges bei den Checks eingeschränkt habe. Wenig elegant.
Wie schön sind dagegen doch die Filter. Kennt man sich ein wenig mit SQL aus, hat man das Prinzip dahinter schnell erkannt. Hinter OpenNMS arbeitet eine PostgresSQL-Datenbank welche die Interfaces, Kategorien, Events etc. verwaltet. Mit den Filtern kann man prinzipiell jedes Feld in dieser Datenbank abfragen und so z.B. die zu pollenden Interfaces bestimmen.
Weiterlesen
5. März 2010
Das nette an den vielen Nagios-Scripten ist, dass diese sich relativ einfach remote über SNMP überwachen lassen. Nagios verarbeitet nämlich am besten einzeilige Statusmeldungen. OpenNMS bzw. SNMP profitiert auch davon. Folgend eine Kurzanleitung für das Script check_drbd…
Weiterlesen
30. Januar 2010
Vor Jahren habe ich für Cacti ein Script geschrieben welches MySQL-Informationen über eine native MySQL-Verbindung ausliest und anzeigt. Jetzt wollte ich das selbe Script eigentlich fit für OpenNMS bzw. SNMP machen.
Die Arbeit kann ich mir zum Glück sparen. Es gibt mittlerweile einen eleganteren Ansatz: mysql-snmp (Projektseite).
Für OpenNMS User wird anscheinend sogar schon die fertige Konfiguration mitgeliefert. Ausprobiert habe ich das ganze noch nicht – werde ich aber sicher sehr bald
15. Dezember 2009
Autodiscovery in OpenNMS ist ein tolles Feature. Leider ist es nicht immer zu gebrauchen, da es derzeit nur begrenzt konfigurierbar ist. So möchte ich z.B. in einem bestimmten Netzbereich nur die jeweiligen Router der Teilnetze abfragen – und nicht alle Hosts auf Services scannen. Klar kann man auch Bereiche excluden bzw. includen – aber ich wollte ja Autodiscovery .
In der kommenden OpenNMS Version 1.8 sollen die Discovery bzw. die Capability-Checks (capsd) von einem neuen Daemon (“provisiond”) abgelöst werden welcher sich wohl auch besser an eigene Bedürfnisse anpassen lässt – z.B. ist als nettes Feature dann z.B. auch der Import von DNS-Zonen möglich. Dies aber nur Nebenbei.
Auf der Suche nach einem alternativen Import bin ich bei XML gelandet. Da die zu überwachenden Hosts in einem internen Wiki (Mediawiki) gepflegt werden, stehen diese über die eingebaute Export-Funktion auch als XML zur verfügung. So ist z.B. der OpenNMS Artikel bei Wikipedia auch als reines XML verfügbar: http://en.wikipedia.org/wiki/Special:Export/OpenNMS.
Ein cooles Tool zum verarbeiten von XML auf der Kommandozeile ist “xml2” (in vielen Distro-Repositories verfügbar). Kombiniert mit ein paar regulären Ausdrücken landen die richtigen IPs in einer Datei für den automatischen Import in OpenNMS:
wget -q -O - --http-user admin --http-passwd secret \
http://wiki.example.com/index.php/Spezial:Exportieren/IP_Plan \
| xml2 \
| awk '/(page\/revision\/text)*([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)*(NMS:host)/ {print $2}' \
> /opt/include-hosts Weiterlesen
19. November 2009
Bisher lief die Einrichtung und Konfiguration von OpenNMS seit einigen Wochen sehr erfolgreich. Anfängliche Konfigurationsfehler sowie die Einrichtung weiterer Services konnten bisher immer mit Hilfe der Mailingliste und des Wikis schnell behoben werden.
Die (für OpenNMS sehr wichtige) SNMP Kommunikation lief aber nicht ganz so zuverlässig. Ab und an erschienen folgende Meldungen im Eventlog:
SNMP data collection on interface x.x.x.x failed.
snmp4j-internal.log lieferte dann andauernd:
Received response that cannot be matched to any outstanding request ...
Merkwürdigerweise immer nur bei bestimmten Hosts… Nach erfolgloser Suche bin ich dann nochmal die Konfiguration durchgegangen. In der snmp-config.xml fand ich dann die Ursache:
<definition timeout="10" read-community="xxx" version="v1">
OpenNMS Experten werden jetzt sicherlich nur süffisant grinsen. Bei der anfänglichen Einrichtung von OpenNMS wusste ich damals noch nicht, dass OpenNMS generell Timeouts in Millisekunden angibt…
So ist es besser:
<definition timeout="10000" read-community="xxx" version="v1">
Erstaunlich das es überhaupt so viele externe Hosts geschafft haben innerhalb der 10ms zu Antworten – spricht für die Infrastruktur