OpenNMS: Jabber/XMPP notifications

Das ist prinzipiell ganz einfach. Anleitung u.A. hier.

Allerdings hatte ich das Problem, dass irgendwann einfach keine Nachrichten mehr verschickt wurden. Wertvoll war ein Hinweis auf der Mailingliste: Man sollte darauf achten, dass jeder potentielle Empfänger auch eine Jabber-Adresse eingetragen hat. Ansonsten kommt es wohl intern zu Ungereimtheiten. Da ich bei den Benachrichtigungen im wesentlichen nur mit Benutzergruppen arbeite, gibt es jetzt eine extra Gruppe „Admins_Jabber“ in welcher dann nur Empfänger sind welche auch eine Jabber-ID haben. Etwas unschön, aber seitdem funktionieren die Jabber Nachrichten zuverlässig.

OpenNMS: Performance tuning

Nachdem OpenNMS zwei Jahre gelaufen ist wurde es zuletzt immer langsamer. Klar, neue Nodes, Services etc. erhöhen die Last. Also Zeit für eine Optimierung. Die in meinem Fall wichtigsten Punkte:

  • Postgres Konfiguration
  • eigene RRD Partition (noatime,nodiratime)
  • Events aufräumen

Generell ist die IO Performance der Bereich worauf es bei OpenNMS am meisten ankommt. Nebenbei bemerkt läuft OpenNMS hier in einer Virtuellen Maschine. Zwar wird generell davon abgeraten OpenNMS in einer VM laufen zu lassen, aber das bezieht sich hauptsächlich auf die meist geringere IO Performance. Da hier in diesem Fall KVM mit virtio (auf lokalem Storage) im Einsatz ist und nicht an einem NAS/SAN hängt ist ist die Warnung denke ich zu vernachlässigen ;).

Bzgl. der Postgres Performance habe ich im wesentlichen die Config von hier übernommen.

Wichtige Links:
http://www.opennms.org/wiki/Performance_tuning
http://www.opennms.org/wiki/RRD_performance_fundamentals
http://www.opennms.org/wiki/Event_Configuration_How-To#The_Database

Vorher/Nachher:

PS. das Nachlassen der Last hat natürlich nichts mit dem Wochenende zu tun…

Firefox 4 RC

Habe mir soeben den Release Candiate von Firefox 4 installiert. Bis jetzt alles sehr positiv. Er fühlt sich vorallem spürbar schneller an als der Vorgänger. Firefox Sync ist jetzt integriert. Schade ist allerdings, dass sich unter Ubuntu/Linux die Tabs und die Menüleiste nicht so verhalten wie bei der neuen Version unter Windows.

Praktisch sind die neuen „App“-Tabs mit denen man häufig benötigte Seiten „anpinnen“ kann. Dabei fällt auf, das OpenNMS noch kein Favicon hat 😉

OpenNMS: Services löschen

Wenn man bei OpenNMS einige Services aus der poller-configuration.xml entfernt, werden diese zwar nicht mehr überwacht, tauchen aber nach wie vor in der Serviceliste des jeweiligen Interface auf („Not Monitored“). Theoretisch sollte OpenNMS diese Services nach 5 Tagen (Default) entfernen. Ich bin mir allerdings nicht sicher ob diese dann komplett entfernt werden oder nur auf „Not Monitored“ gesetzt werden. Die Doku bzw. einige Einträge auf der Mailingliste sind da etwas widersprüchlich – und 5 Tage warten wollte ich nicht.

Manuell können die Services im Webinterface gelöscht werden indem man auf das Interface geht, dann den Service auswählt und schließlich auf „Delete“ klickt. Bei hunderten Interfaces ist das etwas mühsam. Daher habe ich folgendes Script gebastelt welches die gewünschten Services bei allen Nodes und Interfaces löscht (Benutzung auf eigene Gefahr!):

#!/bin/bash
 
for i in `psql -qAt -F";" -c 'select ipaddr,nodeid from ipinterface;' -d opennms opennms`; do
  IF=`echo $i | awk -F ";" '{print $1}'`
  NODE=`echo $i | awk -F ";" '{print $2}'`
  echo "deleting services from $IF on $NODE..."
  # entferne den Service "Qmail-queue" von allen Nodes und Interfaces
  /usr/share/opennms/bin/send-event.pl uei.opennms.org/nodes/deleteService \
  --service Qmail-queue \
  --interface $IF \
  --node $NODE
done;

Auf jeden Fall sollte man die zu entfernenden Services auch aus der capsd-configuration.xml herausnehmen – ansonsten werden diese immer wieder neu erkannt (wiederum als „Not Monitored“).

Linux: Updatefälligkeit checken

Zwei kleine Scripts um unter Ubuntu/Debian oder Centos/RHEL zu checken ob Updates fällig sind. Die Scripts geben jeweils nur die Anzahl der fälligen Updates zurück – eignen sich also prima dazu mittels SNMP die Aktualität der Systeme abzufragen. Ein Beispiel für OpenNMS befindet sich hier (von dort stammt auch das erste Script, das zweite ist IMO eine bessere Variante des dort dargestellten).

Centos/RHEL

#!/bin/bash
yum check-update 2>/dev/null | grep -v Load | grep -v \* | grep -v '^$' \ | wc -l

Ubuntu/Debian

#!/bin/bash
/usr/bin/apt-get update > /dev/null 2>&1
/usr/bin/apt-get -qq -s dist-upgrade --allow-unauthenticated | grep ^Inst | wc -l

OpenNMS: Memcached mit SNMP überwachen

opennmsIn 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>
	<property key="retry" value="1"></property>
	<property key="service-name" value="memcached"></property>
    </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>
    <parameter key="timeout" value="10000"></parameter>
    <parameter key="service-name" value="memcached"></parameter>
    <parameter key="run-level" value="3"></parameter>
    <parameter key="match-all" value="true"></parameter>
</service>
 ...
    <monitor service="Process-memcached" class-name="org.opennms.netmgt.poller.monitors.HostResourceSwRunMonitor"></monitor>

Statistiken

Um noch ein paar Graphen zu generieren werden per SNMP noch die Statusdetails des Memcached Daemons übertragen…

„OpenNMS: Memcached mit SNMP überwachen“ weiterlesen

Update auf OpenNMS 1.8 (Cardinal)

opennmsEs 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…