velt.de

Alternativ-Titel: Keine PNP4Nagios-Graphen mehr mit check_icmp nach Squeeze-Upgrade

Irgendwann zwischen den Releases 1.4.12 (Lenny) und 1.4.15 (Squeeze) sind bei "check_icmp" zwei zusätzliche PerfData-Werte hinzugekommen "rtmin" und "rtmax". Beim Update meiner privaten Nagios-Installation ist mir das natürlich ziemlich auf die Füße gefallen, denn die vorhandenen RRD-Files von PNP4Nagios kannten nur die zwei bisherigen "rta" und "pl" PerfDatas bzw. Datasources.

Jetzt hätte man natürlich einfach alle RRDs, die es betrifft, löschen können, dann hätte sie PNP4Nagios wieder neu angelegt. Aber damit wären dann ja auch die alten Werte verloren gegangen. Also habe ich nach einer Lösung gesucht, wie man die RRD-Dateien erweitern kann.

Da das leider nicht so einfach möglich ist, habe ich mir ein Python-Skript geschrieben, dass letztendlich die Daten aus der RRD-Datei dump't (XML), das XML an den entsprechenden Stellen erweitert, und dann aus diesem "neuen" XML wieder eine RRD-Datei baut. Und siehe da, es funktioniert :)

BITTE VORHER DIE RRD-DATEIEN SICHERN!

Aufruf: add_ds.py [-v] Ping.rrd
Dadurch wir eine neue Datei "Ping.rrd.new" erzeugt, die entsprechend erweitert ist.

Theoretisch wäre es sogar möglich, das Tool folgendermaßen aufzurufen:
cd /var/lib/pnp4nagios/perfdata; add_ds.py --rename */Ping.rrd
ICH würd's aber nur mit einer vorherigen Sicherung machen ;-)

Update 1:
Das Skript ist so (vor)eingestellt, dass es genau für diesen Fall (Lenny->Squeeze) funktioniert.

Update 2:
Noch etwas genauer: Es überprüft, dass genau zwei ("--expect=2") DS/Datasources in der RRD-Datei existieren und fügt dann zwei weitere ("--addds=2") des Typs GAUGE ("--adddstype=GAUGE") hinzu. Über die Parameter kann man dies steuern und natürlich für andere Fälle auch andere Datasources hinzufügen.

Download
Da ich noch nicht ganz schlüssig bin, wo ich das Skript letztendlich hinlegen werde, wird es einfach mal hier angehängt.

Seit Anfang September (Commit auf GitHub) kann Nag(ix)SC nicht nur die Checks selbst ausführen, sondern diese Daten aus aus einem MK-Livestatus Socket lesen. Dabei ist natürlich egal, ob über lokalen UNIX-Socket oder über TCP (es sollte sowohl IPv4 als auch IPv6 funktionieren) abgefragt wird.

Die Funktionalität findet sich einmal in nagixsc_live2xml.py (direktes Erstellen eines XMLs auf der Command Line) und auch in nagixsc_conf2http.py (Als "conf"-File in der URL einfach "_livestatus" verwenden und vorher den Socket-Pfad in der Config hinterlegen).

Ich verwende dieses Feature zur Zeit um von einem (eigentlich unabhängigen) Nagios mir die aktuellen Check-Ergebniss in einem zweiten ("Master") anzeigen zu lassen. Die Nagios-Konfiguration am Master erstelle ich dabei natürlich NICHT von Hand, sondern lasse diese von nagixsc_xml2cfg.py mit entsprechenden Host- und Service-Templates erzeugen.

Wieder mal etwas neues bei Nag(ix)SC. Über die Parameter "plugin_timeout" und "plugin_timeout_returncode" kann man nun einstellen, wie lange ein Plugin laufen darf, bis es mit Timeout abgebrochen wird. Gleichzeitig ist es möglich, dass man den Default-Returncode von "CRITICAL" bzw. 2 auf einen anderen Wert setzt. Zur Demonstration gibt es eine neue Config-Datei "sample-configs/conf/timeout.conf", mit der man sich überzeugen kann, dass es auch wirklich funktioniert ;-)

Und noch eine kleine Änderung: "nagixsc_read_xml.py" sucht nun nicht mehr nach einer Datei "nagixsc.xml", wenn der Parameter "-f" nicht angegeben wurde, sondern liest von der Standardeingabe. Dazu wurde die Ausgabe so verändert, dass die gelesenen Ergebnisse nur noch "menschenlesbar" ausgegeben werden. Wer wieder die "pprint"-Ausgabe haben möchte, nimmt einfach dem Parameter "-P" zu Hilfe.

Ein paar Neuerungen in Nag(ix)SC:

• Neue init.d-Skripts im Verzeichnis "init.d/", getestet auf SuSE 10.2 und Debian - sollten aber auch auf anderen funktionieren
• Sollten die HTTP-Daemons keine PID-Files schreiben können, gibt's nun eine Fehlermeldung bevor der Daemon stirbt
• Für die Config-Files der HTTP-Daemons gibt's jetzt Defaults, welche in "sample-config/*.cfg" ab sofort auskommentiert sind. In diesem Rahmen wurde auch das Parsing der Config-Files etwas umgebaut und (hoffentlich) robuster gemacht

Die nächsten Baustellen:

• Ideen bzgl. redundanter/kaskadierter Installationen auf Basis der "(ocsp|ochp)_commands" und/oder MK-Livestatus weiterverfolgen

Am 01. Juni 2010 war es soweit: Mein Projekt "Nag(ix)SC" wurde im Rahmen des "Nagios-Portal Workshops" der Öffentlichkeit vorgestellt.

Nag(ix)SC versucht eine bessere Alternative zu NRPE und NSCA zu sein. Dazu gehört u.a. das als Transport-Protokoll HTTP(S) verwendet werden kann - durch jede Art von (Reverse-)Proxy!

Da zur Zeit alles ein wenig verstreut liegt, hier mal die wichtigsten URLs:

• Web-Seite, Doku: http://oss.teamix.org/nagios/nagixsc/start
• Quellcode bzw. Git-Repository auf GitHub: http://github.com/wAmpIre/nagixsc
• Download Snapshot master-Branch: http://github.com/wAmpIre/nagixsc/tarball/master
• Nag(ix)SC Bereich auf dem Nagios-Portal: http://www.nagios-portal.org/wbb/index.php?page=Board&boardID=96

Anyone out there?

I'm looking for packaged (RPM) Python bindings of NET SNMP for SUSE 11...

Any hint?

Just a short note:

check_netappfiler's code is now available on GitHub. I didn't import the whole history (just the last... uh... about 6 "releases") because there was(is) much crap in my original Subversion repository.

Fork it! Add code! Fix errors! Send "pull request"s! ;-)

I'm not sure if it while be there forever - but hey! Let's use this wonderful site!

Dieser Artikel liegt schon ewig in meiner Queue, bevor er hier endgültig vergammelt geb ich ihn einfach mal so frei

Auslesen der Mess-PC Temperaturfühler unter Windows mit Hilfe von Python:

#!/usr/bin/env python

import re
import sys

fd = open("COM3")

line = fd.readline()
line = fd.readline()

fd.close()

erg = re.search("temperature=([.0-9]+).*humidity=([.0-9]+).*dewpoint=([.0-9]+)", line)

temp = float(erg.group(1))

RETURNCODE=0
RETURNSTRING='OK'

if temp > 40.0:
	RETURNCODE=1
	RETURNSTRING='WARNING'
elif temp > 45.0:
	RETURNCODE=2
	RETURNSTRING='CRITICAL'

out  =  'Temperatur %s: %4.1f C, ' % (RETURNSTRING, temp)
out +=  'Information: Luftfeuchte %4.1f%%, ' % float(erg.group(2))
out +=  'Taupunkt %4.1f' % float(erg.group(3))

out += '|Temperatur=%.1f;40.0;45.0; ' % temp
out += 'Luftfeuchtigkeit=%.1f ' % float(erg.group(2)
out += 'Taupunkt=%.1f' % float(erg.group(3))

print out
sys.exit(RETURNCODE)

Mit Hilfe von check_netappfiler ist es möglich, wichtige Laufzeitdaten einer FAS mit Nagios zu überwachen. Das Plugin ist in Python geschrieben und hat außer dem "snmpget"-Binary keinerlei Abhängigkeiten.

Es existiert allerdings eine Version, welche auf den NET-SNMP Python-Bindings aufsetzt - diese ist zwar schneller, dafür werden aber die Bindings benötigt, welche noch nicht in allen Distributionen (z.B. nicht in Debian 4.0 "Etch", aber in 5.0 "Lenny") zu finden sind.

Grafische Visualisierung mit Hilfe von PNP und RRDTool

Es gibt noch keine richtige HomePage für das Plugin, allerdings ein paar Informationen dazu (auf Englisch) befinden sich unter http://people.teamix.net/~svelt/check_netappfiler/.

Wer sich weiterhin mit NetApps beschäftigt (oder beschäftigen muss), dem sei MyNetApp.de an's Herz gelegt. Eine kleine aber feine Community mit vielen Tipps, Tricks und schnellen Antworten auf Fragen!

I just want to let you know that there is a new... err... "homepage" for my check_netappfiler-Plugin. You can find it - as I do most work for it at team(ix) - on http://people.teamix.net/~svelt/check_netappfiler/. There are also some example graphs of PNP4Nagios.

If you have problems and/or ideas what to monitor on your NetApp Toaste^WFAS don't hesitate to contact me!

German readers: Soll ich noch ein Forum auf MyNetApp.de eröffnen (lassen)?

As ''snmpget'' from Debian Etch is a real performance killer I rewrote parts of my check_netappfiler plugin for Nagios.

The Good News[tm]:
Look at the load at the time of switchting to the new version:

The Bad News[tm]:
You need NET-SNMP's Python bindings which aren't in Debian/Etch so I did a quick ("works for me") backport of NET-SNMP out of Lenny

Feedback welcome! ;-)

Some people asked me at NETWAYS Nagios Konferenz if my check_netappfiler plugin is dead.

No, it's not!

With ONTAP 7.3 NetApp added support for SNMP v2c and v3! W00t!

Get the plugin (and some minimal documenation - you have been warned! ;) on http://people.teamix.net/~svelt/check_netappfiler/!

And PLEASE send me feedback (yes, "it's wonderful!" IS feedback ;) if you're using it!

Durch einen Artikel im aktuellen Linux-Magazin (04/2008) bin ich auf das Portal Ohloh aufmerksam geworden. Das schöne an diesem Portal ist, dass sie die eingestellten Software-Projekte analysieren. Je Sprache kann man sich diverse Statistiken ansehen. Besonders lachen musste ich über die Anzahl der Kommentare in den 3 angesprochenen Sprachen:

• Python: 11,8%
• PERL: 20,9%
• Ruby: 20,8%

Fangen wir mal mit meiner Interpretation bei PERL an:

Der Code ist klein (durch die schon angesprochenen Sonderzeichen...), dafür muss der Code einigermaßen ausführlich kommentiert werden, damit selbst der Programmierer nach 14 Tagen noch weiss, was er denn da angestellt hat.

Bei Python wird die Kommentierung am Anfang der Methode/Funktion vorgenommen, was das Ding gesamt macht. Eine Kommentierung des Codes ist nur an besonderen Stellen notwendig, da der Code für sich selbst spricht, man kann ihn sofort sinnentnehmend lesen. (Oder wie man es auch ausdrücken könnte: "Du musst Deinen Code kommentieren, damit jemand anders weiß, was Du da tust? Dann verwende die Zeit besser darauf, Deinen Code ordentlich zu schreiben!")

Die Interpretation für Ruby spare ich mir hier mal, sonst gibbet noch mehr Haue ;-)

Weitere Zahlen: C/C++: 20,0%, PHP: 27,9% - passt auch irgendwie ;->

Naja, immerhin 3 Rückmeldungen öffentlich - und einige, die sich nicht getraut haben, es öffentlich zu machen ;-)

Hier also nun der schon versprochene 2. Teil zu Ruby... Was mir als erstes entgegengehalten wurde war, dass man

@names.each do |name|
puts "Hallo, #{name}!"
end

auch so schreiben kann:

for name in names do
puts "Hallo, " + name
end


<rant>
Wenn ich eine Sprache suche, in der die einfachsten Dinge mit 27 Gazillionen verschiedenen Möglichkeiten realisierbar sind, dann nehm ich PERL. Ich will anderer Leute Code lesen können, OHNE vorher die Sonderzeichen der jeweiligen Sprache studiert zu haben. Nachwievor IMHO das Argument gegen PERL. Und Ruby ist - siehe Kommentar und Trackbacks zum ersten Eintrag - nicht wirklich besser.
</rant>

Und wenn ich dann sowas im Code sehe wie

1.upto 3 do

dann muss ich ehrlich sagen: Nein, danke! Da schreib ich lieber noch ein wenig mehr Python-Code, der ist lesbar und selbst Python-Code von ganz anderen Leute (aka praktisch jedes Script, das ich mir aus dem Netz angesehen habe) kann ich lesen - ohne mich auf des Autors Eigenheiten einstellen zu müssen.

Ich bin mal wieder bei einem Ruby-Tutorial hängen geblieben und musste mir das unbedingt ansehen. Doch auf der vierten (und letzten Seite) wurde mir dann wieder bewusst, warum ich Ruby nicht mag:

@names.each do |name|
puts "Hallo, #{name}!"
end


Err, jaanee, is klar. Wozu "@names" (statt "names"), wieso "|name|" (statt "name") und warum zur Hölle "#{name}"? Bei dieser Ansammlung von Sonderzeichen hier kann ich gleich wieder Perl programmieren...

Apropos Perl:

foreach my $name (@NAMES) {
print $name."\n";
}


Sieht ja in dem Fall fast noch erträglich aus (IMHO erträglicher als Ruby, wobei man sich natürlich auch nach dem Sinn und Zweck des "@" fragen muss - insbesondere im Gegensatz/Vergleich zum "$". YMMV.)

Wie würde es in Python aussehen? So:

for name in names:
print "Hallo, %s!" % name
# Alternativ: print "Hallo, " + foo + "!"


Bei der Ausgabe fällt mir auf, dass wir schon bei PHP verflucht haben, dass man einfach "$name" irgendwo in den String reinschreibt (ähnlich wie bei dem Ruby-Beispiel oben) - so von wegen saubere Trennung von Variablen und Strings... Ja, geht bestimmt bei Ruby auch anders, ich weiß. Allgemein fällt mir dazu auf, dass da jede Sprach wohl so seine Eigenheiten hat. Ich hab mich in Python auf die "Platzhalter-Syntax" eingeschossen, ist mir symaptischer als die Alternativ-Variante.

PS: Kommentare ausdrücklich erwünscht!