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…

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“).

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.

„OpenNMS: Nur primäre Interfaces überwachen“ weiterlesen