SMS verschicken, wenn man offline ist …

Coole Idee. SMS Versand mit Jabber zu verbinden und nur SMS raus zu hauen, wenn man offline ist. Obwohl die Bauanleitung für Nagios und nicht SMS Server Tools ist, kann man sie doch super einfach umbauen.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

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…

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

HostMonitor = Nagios unter Windows (nur besser)

Wer als Windows User sich schon immer für Nagios interessiert hat nur nicht ein Unix/Linux Programm einsetzen wollte, der sollte sich unbedingt mal den HostMonitor ansehen. Das Teil ist Nagios mehr als eben würdig. Der HostMonitor …

  • bringt von Haus aus einige Standard-Tests mit.
  • kann Skripts wie Nagios (auch per ssh) ausführen
  • kann über diverse Pfade alarmieren.
  • kann Unix/Linux Systeme problemlos überwachen.
  • kann verteilt installiert werden.
  • kann über ein Webinterface administriert weden.
  • kann verschiedenen Usern verschiedenen Rechte geben.
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Temperatur/Luftfeuchteüberwachung für 50€

Falls jemand eine günstige Lösung für die Überwachung von Luftfeuchte und Temperatur sucht, der sollte sich mal DLP-TH1b von FTDIChip ansehen. Das Teil wird per USB angeschlossen. Soll’s im Netzwerk hängen, dann würde ich einfach ein Alix-Board nehmen und x-Sensoren dran hängen. Günstiger geht’s nicht…

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

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

            <group name="NTP" ifType="ignore">
                <mibObj oid=".1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101" instance="1" alias="NTPdelay" type="integer" />
                <mibObj oid=".1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101" instance="2" alias="NTPoffset" type="integer" />
                <mibObj oid=".1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101" instance="3" alias="NTPjitter" type="integer" />
                <mibObj oid=".1.3.6.1.4.1.8072.1.3.2.4.1.2.8.110.116.112.45.116.105.109.101" instance="4" alias="NTPstratum" type="integer" />
            </group>

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
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

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
VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Nagios XI

Sorry Ethan! Aber seitdem ich OpenNMS kenne würde ich nicht einen Cent für nagios XI ausgeben. OpenNMS ist nicht ein zusammen würfeln von verschiedenen Projekten, sondern ein Projekt in einem Stück. Fast komplett und wesentlich besser geplant. Lohnt nicht mehr sich mit Nagios oder einen seiner Ableger zu beschäftigen

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)

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

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

falsche Internet Geschwindigkeit via snmp

Bei manchen Interfaces wird leider die Geschwindigkeit der Interfaces per SNMP nicht richtig erkannt. Wird etwa ein 1GBit Interface als 100MBit erkann und überwacht man die Auslastung kann das schnell zu einer Flut von Meldungen mit einer Auslastung von über 100% kommen. Das ist mir auch passiert. Auf meinen Servern sind die Bonding Interface nicht richtig erkannt worden. Daher habe ich das manuell in der snmpd.conf konfiguriert:

interface bond0      6 1000000000
interface br0      209 1000000000
interface bond0.77 135 1000000000

Den richten Typ des Interfaces bekommt man übrigens hier raus.

Hat jemand eine Idee, wie ich mir den manuellen Aufwand sparen kann?

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

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:

<service>
        <name>OpenNMS:Name=Linkd</name>
        <class-name>org.opennms.netmgt.linkd.jmx.Linkd</class-name>
                <invoke at="start" pass="0" method="init"/>
                <invoke at="start" pass="1" method="start"/>
                <invoke at="status" pass="0" method="status"/>
                <invoke at="stop" pass="0" method="stop"/>
 </service>

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.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)