Categories
Linux

OpenNMS: Nur primäre Interfaces überwachen

opennmsOpenNMS 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.

Categories
Linux Networking

OpenNMS: DRBD überwachen

opennmsDas 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

Categories
Linux

SNMP-Agent für MySQL

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 ;)

Categories
Linux

OpenNMS: Import aus XML

opennmsAutodiscovery 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
Categories
Linux

OpenNMS: SNMP data collection failed

opennmsBisher 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:

    

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:

    

Erstaunlich das es überhaupt so viele externe Hosts geschafft haben innerhalb der 10ms zu Antworten – spricht für die Infrastruktur ;)