OpenNMS maps und Reports

Warum finde ich solche Infos immer erst per Zufall:

  1. OpenNMS Automatic Map Creation
    Wie cool ist das denn. Ruckzuck die Bereiche definiert und schon sind die Maps da. Endlich hat die Geschäftsleitung die Dokumentation, die sie schon lange wollte 😀
  2. OpenNMS Reporting CheatSheet
    Und damit lassen sich ruck zuck mit der integrierten JasperReporting Engine richtig coole Reports erstellen.

Mittlerweile kommt mir Nagios so amateurhaft vor. Alle Features, die OpenNMS mitbringt müssen manuell nachgerüstet werden…

OpenNMS überwacht NTP

NTP zu überwachen ist relativ komplex. Dabei ist die Überwachung der Zeitdifferenz zu einer NTP Quelle relativ einfach. Was das ganze komplex macht ist NTP selbst. D.h. die beste NTP Überwachung nützt nichts, wenn man NTP nicht verstanden hat und NTP auf den jeweiligen Servern nicht richtig konfiguriert hat. Hier geht’s aber nur um die Basisüberwachung von NTP per OpenNMS.

Bei der NTP-Überwachung nehme ich ntpq. Dabei nutze ich, dass das Tool den aktuell besten peer mit einem Stern „*“ markiert. Das ganze packe ich in ein kleines Skript /usr/local/bin/ntp-time.sh :

#!/bin/sh
ntpq -pn localhost | /usr/bin/awk 'BEGIN { delay=1000; offset=1000; jitter=1000; stratum=16 } $1 ~ /\*/ { delay=$8; offset=$9; jitter=$10; stratum=$3 } END { print int(delay)"\n"int(offset)"\n"int(jitter)"\n"stratum }'

Dieses Skript wiederum integriere ich in den snmp daemon (snmpd.conf):

extend ntp-time /usr/local/bin/ntp-tim.sh 

Kurzer lokaler Test nach dem „/etc/init.d/snmpd reload“ ob es funktioniert:

snmpwalk -v2c -cpublic localhost -On .1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101
.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101.1 = STRING: 14
.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101.2 = STRING: 0
.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101.3 = STRING: 0
.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101.4 = STRING: 2

Funktioniert das, dann kann es in OpenNMS eingebaut werden:
datacollection-config.xml

            
                
                
                
                
            

snmp-graph.properties

reports=ntp.overview, ntp.stratum \

report.ntp.overview.name=NTP Overview
report.ntp.overview.columns=NTPdelay, NTPoffset, NTPjitter
report.ntp.overview.type=nodeSnmp
report.ntp.overview.command=--title="NTP Overview" --units-exponent=0 \
 --vertical-label="miliseconds" \
 DEF:delay={rrd1}:NTPdelay:AVERAGE \
 DEF:mindelay={rrd1}:NTPdelay:MIN \
 DEF:maxdelay={rrd1}:NTPdelay:MAX \
 DEF:offset={rrd2}:NTPoffset:AVERAGE \
 DEF:minoffset={rrd2}:NTPoffset:MIN \
 DEF:maxoffset={rrd2}:NTPoffset:MAX \
 DEF:jitter={rrd3}:NTPjitter:AVERAGE \
 DEF:minjitter={rrd3}:NTPjitter:MIN \
 DEF:maxjitter={rrd3}:NTPjitter:MAX \
 LINE2:delay#0000ff:"Delay " \
 GPRINT:delay:AVERAGE:"Avg \\: %10.2lf" \
 GPRINT:delay:MIN:"Min \\: %10.2lf" \
 GPRINT:delay:MAX:"Max \\: %10.2lf\\n" \
 LINE2:offset#00ff00:"Offset" \
 GPRINT:offset:AVERAGE:"Avg \\: %10.2lf" \
 GPRINT:offset:MIN:"Min \\: %10.2lf" \
 GPRINT:offset:MAX:"Max \\: %10.2lf\\n" \
 LINE2:jitter#ff0000:"Jitter" \
 GPRINT:jitter:AVERAGE:"Avg \\: %10.2lf" \
 GPRINT:jitter:MIN:"Min \\: %10.2lf" \
 GPRINT:jitter:MAX:"Max \\: %10.2lf\\n" 

report.ntp.stratum.name=NTP Stratum
report.ntp.stratum.columns=NTPstratum
report.ntp.stratum.type=nodeSnmp
report.ntp.stratum.command=--title="NTP Stratum" --units-exponent=0 \
 --vertical-label="stratum" \
 DEF:stratum={rrd1}:NTPstratum:AVERAGE \
 DEF:minstratum={rrd1}:NTPstratum:MIN \
 DEF:maxstratum={rrd1}:NTPstratum:MAX \
 LINE2:stratum#0000ff:"Stratum" \
 GPRINT:stratum:AVERAGE:"Avg \\: %10.2lf" \
 GPRINT:stratum:MIN:"Min \\: %10.2lf" \
 GPRINT:stratum:MAX:"Max \\: %10.2lf\\n" 

Fertig!

Ein paar Bemerkungen dazu:

  1. Ich bin mittlerweile ein Fan von SNMP. Ruckzuck ist der lokale snmp daemon erweitert und dank extend muss man sich nicht um OIDs sorgen. Die OID für „extend ntp-time“ bekommt man mit
    snmptranslate NET-SNMP-EXTEND-MIB::nsExtendOutLine."ntp-time"
    
  2. Thresholds und damit die Alarme muss man natürlich wie gewohnt in OpenNMS anlegen
  3. Mit dem Skript überwache ich nur auf Milisekunden genau. Das Reicht mir

OpenNMS neue Configfiles (.xml.rpmnew) einspielen

Wenn man wie ich OpenNMS immer die neueste OpeNMS Version benutzt, dann muss man damit leben, dass ständig neue Configfiles von OpenNMS kommen. Ich lass OpenNMS auf CentOS laufen. Damit kommen die neuen Files als .xml.rpmnew an. Nachdem ich nun auch viel an den Configfiles an meine Bedürfnisse anpasse ist das Update immer ein Merge der beiden Files. Ich habe dafür eine ganz einfache Methode, die ich mir hier mal aufschreiben, dann muss ich nicht immer den Befehl suchen :):

  1. Configfiles standardisieren
    Nachdem beide XML Files immer komplett verschieden formatiert sind, standardisiere ich sie erstmal. Hier ein Beispiel:

    /opt/opennms/bin/xml.reader.pl -w jmx-datacollection-config.xml.rpmnew
    /opt/opennms/bin/xml.reader.pl -w jmx-datacollection-config.xml
    
  2. Diff/Merge
    Danach erstelle ich mir einen Merge

    sdiff -o jmx-datacollection-config.xml.new jmx-datacollection-config.xml.rpmnew jmx-datacollection-config.xml
    
  3. Config austauschen
    Anschließend sichere ich mir jmx-datacollection-config.xml.rpmnew und jmx-datacollection-config.xml und benenne jmx-datacollection-config.xml.new in jmx-datacollection-config.xml um. Fertig

tcp keepalives und timeouts

Nachdem ich mit einer kommerziellen bei Idle-Verbindungen immer rausgeflogen bin habe ich mir das Thema mal auf Linux Büchsen genauer angesehen. Es gibt zwei wichtige Schrauben:

  1. /proc/sys/net/ipv4/tcp_keepalive*
    Über die 3 Kernel Parameter tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes kann man dem Kernel mit geben wie häufig er Keepalive Pakete verschickt. Das hilft, wenn man zwischen Client und Server eben solch kommerziellen Firewalls hat, die eine idlen Verbindung sehr schnell trennen. Details dazu hier.
  2. /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_*
    Über diese Kernel Parameter regelt man auf Linux Firewalls selbst wie hoch die entsprechenden Timeouts sind. Am wichtigsten ist hier wohl der Parameter ip_conntrack_tcp_timeout_establishe, welcher per Default auf 432000 Sekunden (=5 Tage) steht. D.h. Linux-Firewalls würden per Default erst nach 5 Tagen idle Verbindungen trennen. Speziell auf Firewalls mit viel Traffic kann es schon mal vernünftig sein, den Wert zu verkleinern. Bei der kommerziellen Firewall, die mich genervt hatte, waren 30 Minuten eingestellt. Ein zu hoher Wert kann im schlimmsten Fall dafür sorgen, dass die Conntrack Tabelle voll läuft und man eine Meldung wie diese bekommt:

    Nov 20 12:43:24 hostname kernel: ip_conntrack: table full, dropping packet.
    

    Nicht schön!

    Die Anzahl der aktuell aktiven und inaktiven TCP Verbindungen kann man übrigens ganz leicht per snmp abfragen. Die beiden OIDs sind .1.3.6.1.2.1.6.5.0 für aktive und .1.3.6.1.2.1.6.6.0 für passive (das kann OpenNMS von Haus auf). Direkt am System geht es gesamt mit:

    [root@host]# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
    10333
    

    Bei der Unterscheidung zwischen den einzelnen Stati hilft grep, awk, sort … 🙂

PS: Wie die Parameter über den Reboot hin rettet erklärt man sysctl bzw. man sysctl.conf

Asterisk und SNMP

Asterisk mit SNMP zu überwachen ist wirklich ein Kinderspiel. Folgende Dinge sind notwendig.

  1. res_snmp.so Modul
    Übersetzt man Asterisk per Hand muss man nur darauf achten, dass die entsprechenden net-snmp Sourcen auf dem System liegen
  2. /etc/asterisk/res_snmp.conf
    [general]
    subagent = yes
    enabled = yes
    
  3. /etc/snmp/snmpd.conf
    um folgende Dinge ergänzen:

    master agentx
    agentXSocket /var/agentx/master
    agentXPerms 0660 0550 nobody asterisk
    

    Die beiden ersten Zeilen sind evtl. schon vorhanden. Außerdem muss hier asterisk der User sein unter dem asterisk läuft.

Noch kurz snmp und Asterisk neu starten. Fertig!

Nachdem ich mein System mit OpenNMS überwachen werden nach einem SNMP Update sofort die entsprechenden Graphen gezeichnet. Sehr schön 🙂

„Multigraphen“ mit OpenNMS

Als ich mir mal den NagiosGrapher ausgedacht habe, war mir wichtig, dass Werte von verschiedenen Hosts sich in einen Graphen darstellen lassen können. Ein klassisches Einsatzbeispiel hierfür war, ob der Loadbalancer auch die Sessions ordentlich über die Nodes verteilt. Beim NagiosGrapher haben wir das damals „Multigraphen“ getauft. multigrapher
Bei OpenNMS kann ich zwar die Graphen verschiedener Rechner zu einem eigenen Report super eays zusammenklicken (per KSC Report) aber was vergleichbares wie im Bild oben geht per Webinterface nicht. Jetzt habe ich dank der Newsgroup einen guten Ansatz gefunden. Er ist hier im OpenNMS Wiki dokumentiert. Ein wenig Handarbeit ist notwendig aber kompliziert ist die Sache nicht. Den Link muss ich mir merken.

OpenNMS und Layer2

OpenNMS kümmert sich um mehr als Layer3 (IP) aus dem Osi-Modell aufwärts. Es sorgt sich auch um Layer2 (MAC). Schon mal super ist, dass man im Webinterface nach Mac-Adressen suchen kann. Aber OpenNMS kann noch mehr. Der Service linkd kümmert sich um die Netzwerktopologie es reicht ihn wie folge zu enablen:
service-configuration.xml:


        OpenNMS:Name=Linkd
        org.opennms.netmgt.linkd.jmx.Linkd
                
                
                
                
 

Dann kann man in link.log seine Arbeit verfolgen. Coole Sache! Keine umständliche Parent-Konfiguration wie in Nagios. Ausserdem wird die Information auch bei dem Erstellen der Maps gleich mit eingebaut.

OpenNMS überwacht Windows Performance Counter

Microsoft hat leider SNMP in allen gängigen Windows Betriebssystemen nicht vollständig integriert. Es geht einfach nicht alle Performance Counter ohne Extension Agents abzufragen. Ok, es gibt Software dafür aber die kostet teilweise richtig Geld. Also muss eine Alternative her! OpenNMS hat zu diesem Zweck eine Schnittstelle für den von Nagios bekannten NSClient++ integriert. Die Einrichtung ist denkbar einfach:
capsd-configuration.xml:

    
        
        
        
        
    

poller-configuration.xml:

   
      
      
      
    
 

nsclient-config.xml:




nsclient-datacollection-config.xml:



  
    
      RRA:AVERAGE:0.5:1:2016
      RRA:AVERAGE:0.5:12:1488
      RRA:AVERAGE:0.5:288:366
      RRA:MAX:0.5:288:366
      RRA:MIN:0.5:288:366
    

    
      
        
      
      
        
      
      
        
      
      
        
      

    
  

Wichtig ist zur Zeit noch, dass die wpms nicht gruppiert werden. Ein Fehler in OpenNMS verhindert aktuell noch, dass mehr wie ein Wert pro wpm gespeichert wird.

Anschließend können die Thresholds und Graphen definiert werden.