by ·2 Kommentare

Das Zabbix-Item

Das Zabbix-Item

Lange Zeit habe ich die Überwachung meines Netzwerkes Nagios anvertraut. Vor einiger Zeit habe ich das durch ein Icinga ersetzt, einfach nur um mal zu sehen inwiefern der Fork besser oder anders ist. Seit einigen Wochen beschäftige ich mich aber aus verschiedenen Gründen mit Zabbix, und das ist auf dem besten Wege sowohl Nagios als auch Icinga zu verbannen. Zabbix kann einfach viel mehr als Nagios/Icinga, und wenn man sich an die Konzepte gewöhnt hat ist es absolut nicht schwieriger zu beherrschen.

Eine der letzten Überwachungen die Nagios und Icinga bei mir gemacht haben, Zabbix aber noch nicht, war der Test auf aktualisierte Softwarepakete. Da die meisten Systeme unter meiner Fuchtel unter Debian laufen ist das nicht allzu schwer. Bislang habe ich regelmäßig durch den Nagios Remote Plugin Executor (NRPE) ein apt-get update && apt-get upgrade ausgeführt und rausgeparst wie viele Pakete aktualisiert würden. Das hat mehrere Nachteile: zum einen sind die Prozesse — gerade bei meiner schmalen Internetanbindung — teilweise recht lange unterwegs, und das führt zu Timeouts. Zum anderen bekommt das Monitoring erst beim nächsten Test mit dass ein System aktualisiert wurde, und da ich meine Kisten nicht unnötig stressen will teste ich nur zweimal täglich. Das bedeutet, dass ein Alarm unter Umständen knapp zwölf Stunden weiter besteht, obwohl die Situation schon bereinigt wurde.

Das geht besser.

Ich vermute dass das auch mit Nagios/Icinga besser ginge, aber ich gestehe dass ich damals nicht die Zeit investiert habe. Für Zabbix habe ich jetzt eine Lösung die mir gut gefällt:

Im nebenstehenden Bild sieht man den Parameter (Zabbix-Sprech: ‚das Item‘) das ich dazu angelegt habe. Das ist in meiner Konfiguration das erste Item vom Typ Zabbix-Trapper, daher stelle ich das hier mal vor. Zabbix-Trapper bedeutet, dass der Parameter nicht aktiv gepollt wird. Zabbix wartet passiv darauf, dass jemand mittels zabbix_sender einen Wert in das System schießt. Das funktioniert natürlich sowohl direkt bei Übergabe an den Zabbix-Server, als auch bei Übergabe an einen Zabbix-Proxy (ja, auch so einen habe ich zu Hause… ;-) ).

Nur wer sagt jetzt beim Zabbix Bescheid ob Pakete zu aktualisieren sind? Keine schlechte Idee ist, regelmäßig ein apt-get update auszuführen, um den Katalog aufzufrischen. Das erledigt Cron gerne, dem könnte man dann auch direkt sagen dass er den aktuellen Wert an Zabbix schicken soll. Das würde aber bedeuten, dass das Problem mit der Verzögerung nach einer Auffrischung des Systems immer noch bestünde. Also habe ich mir Apt mal etwas näher angesehen.

Im Verzeichnis /etc/apt/apt.conf.d/ kann man Hooks ablegen die vor oder nach bestimmten Aktionen des Paketmanagements ausgeführt werden. Bei mir gibt es da jetzt eine Datei namens 99zabbix, die hat einen Inhalt in dieser Form:

APT::Update::Post-Invoke-Success { "zabbix_sender -z zabbix.intern -s $(hostname -s).intern -k debian.updates -o $(apt-get -s upgrade | sed -ne 's/^\([0-9][0-9]*\) .*/\1/p') > /dev/null" };
DPkg::Post-Invoke { "zabbix_sender -z zabbix.intern -s $(hostname -s).intern -k debian.updates -o $(apt-get -s upgrade | sed -ne 's/^\([0-9][0-9]*\) .*/\1/p') > /dev/null" };

Das Kommando ist in beiden Fällen das gleiche. Mit APT::Update::Post-Invoke-Success wird festgelegt was nach einem erfolgreichen apt-get update passieren soll. So bekommt Zabbix nach jedem Update mit ob es etwas neues gibt, unabhängig davon ob Cron das angestossen hat oder ob ich das manuell war. Der Eintrag DPkg::Post-Invoke sagt nach jeder Änderung an den installierten Paketen noch einmal Bescheid wie der Stand der Dinge ist. So wird also nach einem apt-get upgrade der Wert direkt wieder auf 0 zurückgesetzt.

Dazu habe ich folgenden Trigger gebaut:

{Template OS Linux:debian.updates.last(0)}>0

Der meldet bislang nur, wenn der letzte Wert in dem Item debian.updates größer ist als 0. Da muss ich aber noch einmal Hand anlegen, so dass der auch aktiv wird wenn seit einer gewissen Zeit kein aktueller Wert gesetzt wurde. Dann ist davon auszugehen dass der Cron-Job kaputt ist der das apt-get update ausführt, oder dass an der Paketverwaltung grundsätzlich etwas schief läuft. Aber wie das geht muss ich mir noch genauer ansehen…

by ·3 Kommentare

Leider weiß ich nicht mehr genau wer mich auf Boodler gestoßen hat. Falls Du dies liest: Danke nochmal. :-)

Boodler ist ein ‚Open-Source Soundscape Tool‘. Das bedeutet, dass man damit Klanglandschaften erzeugen kann. Ein greifbares Beispiel dürfte ein Gewitter sein. Der Klang eines Gewitters besteht in erster Linie aus Regen, Donner und vielleicht Sturm. Boodler verfügt über Module die diese Klänge wiedergeben können. Und es gibt eben ein Modul das dafür sorgen kann dass es durchgehend regnet, es dabei mal mehr, mal weniger stark stürmt, und in natürlich wirkenden Abständen donnert. Ich war skeptisch, muss aber sagen dass die Ergebnisse halbwegs überzeugen.

Kurz zur Technik: Boodler ist in Python geschrieben. Die verschiedenen Module lassen sich einzeln herunterladen, dabei können heruntergeladene Ressourcen von mehreren Modulen benutzt werden. Ressourcen sind nach meinem bisherigen Verständnis die Sounds, sowie die ‚Agenten‘ die wissen wie man die Sounds wiederzugeben hat.

Dabei kann Boodler auch extern angesteuert werden. Es kann am Netz lauschen und Events von anderen Rechnern verarbeiten. Um im Beispiel zu bleiben: man kann es sicher mit vertretbarem Aufwand hinkriegen, das Gewitter von weitem zu steuern. Also Intensität von Regen und Sturm, und Auftreten des Donners.

OK, soviel dazu.

Jetzt bin ich ein großer Freund von Monitoring. Ich habe hier zu Hause aktuell ein Icinga im Einsatz, den Nachfolger von Nagios. Sicher kann man das einfach so weit kriegen dass es bei Boodler bescheid sagt und es gewittermäßig ordentlich krachen lässt wenn irgendwo ein Alarm auftritt. :-D

Im Moment habe ich anderes zu tun, und ein Dauergewitter würde dem einen oder anderen hier zu Hause auf den Keks gehen. Aber irgendwer sollte das dringend mal umsetzen, finde ich…

by ·Keine Kommentare

Die aktuelle Karte

Alles im grünen Bereich

Nein, ich denke nicht dass man sich in anbetracht der aktuellen Situation in Japan Sorgen machen muss dass wir hier in Deutschland direkt von den Auswirkungen der Reaktorkatastrophen betroffen sein werden. Da sind andere viel (viel!) schlimmer dran als wir…

Trotzdem wird natürlich auch hier eine Menge über die lokale Situation berichtet. Unter anderem habe ich gerade erfahren dass direkt in meiner Wohngegend eine Messstation des Bundesamtes für Strahlenschutz steht. Die Betreiben unter dem Namen IMIS ein ‚integriertes Mess- und Informations-System‘, das ist ein Netzwerk aus etwa 1.800 Stationen die flächendeckend in ganz Deutschland die Strahlung messen.

Man kann sogar die aktuelle Situation abrufen. Im Überblick als Karte, oder direkt als Histogramm einer einzelnen Station.

Ein weiterer Messwert den ich bei Gelegenheit mal in meinen Nagios einbauen könnte… ;-)

by ·Keine Kommentare

In den letzten Tagen habe ich nach längerer Pause mal wieder ausgiebig mit Nagios gespielt. Bei einer ausgiebigen Umstellung meines Netzes habe ich vor einer Weile den alten Nagios nach /dev/null verschoben, seitdem gab es Blindflug.

Soweit alles prima, allerdings bin ich an einer Stelle hängen geblieben: dem Drucker. Klar kann man einen Laserjet mit Netzwerkkarte problemlos überwachen, problematisch ist nur dass mein Drucker nur alle paar Wochen mal benutzt wird. Dazwischen ist der natürlich ausgeschaltet.

Das Problem: Wenn ich den Drucker ausschalte werden weiter alle Parameter (Tonerstand, Papiervorrat, Nachrichten…) geprüft, was natürlich nur zu Fehlern oder Nonsens führt. Besser fände ich wenn die Parameter den alten Zustand beibehalten würden, und lediglich das Gerät als ausgeschaltet gemeldet wird. Offenbar kann man das so aber nicht konfigurieren. Zumindest habe ich das nicht gefunden, für sachdienliche Hinweise wäre ich dankbar.

Ich habe vorhin mal ein wenig gescriptet, mit diesem Stück Shell geht es dann doch:

#!/bin/sh
host=$1
shift
command=$@
CACHEFILE=/tmp/check_cached.dat
if ping -c 1 $host > /dev/null; then
  # $host is online, fetch fresh data
  output=$(eval $command)
  returncode=$?
  # escape command and remove old entry from cache file
  ecommand=$(echo $command | sed -e "s_/_\/_g")
  sed -i "/^$ecommand;/d" $CACHEFILE
  # append command with fresh values to cache file
  echo "$command;$returncode;$output" >> $CACHEFILE
else
  # $host is offline, fetch data from cache file
  output="cached: $(sed -ne "s#^$command;[0-9];(.*)$#1#p" $CACHEFILE)"
  returncode=$(sed -ne "s#^$command;([0-9]).*$#1#p" $CACHEFILE)
fi
echo "$output"
exit $returncode

Ich habe das unter dem Namen check_cached.sh gespeichert. Jetzt musste ich nur noch das Kommando ändern mit dem der Drucker kontrolliert wird:

define command{
  command_name check_snmp_printer
  command_line /usr/local/nagios/plugins/check_snmp_printer '$HOSTADDRESS$' '$ARG1$' '$ARG2$' '$ARG3$'
}

Daraus mache ich folgendes:

define command{
  command_name check_snmp_printer
  command_line /usr/local/nagios/plugins/check_cached.sh '$HOSTADDRESS$' "/usr/local/nagios/plugins/check_snmp_printer '$HOSTADDRESS$' '$ARG1$' '$ARG2$' '$ARG3$'"
}

Alle Services die check_snmp_printer benutzen sind ab sofort gecached. Rein theoretisch sollte das auch mit allen anderen Checks funktionieren, ich habe das aber selbst mit diesem bis jetzt nur oberflächlich getestet, ich übernehme (natürlich) keine Verantwortung für alles was mit dem Skript oder wegen des Skriptes passiert. :-)

Fragen und Vorschläge fühlen sich hier in den Kommentaren wohl. :-)

Oh, und eine Frage kann ich im Voraus beantworten: Nein, eigentlich brauche ich kein so dickes Netzwerkmanagement in meinem Heim-Netz. Grund für die Bastelei ist Spaß an der Sache, und nachdem ich in letzter Zeit mit einem teuren kommerziellen System arbeiten muss will ich mir zu Hause einfach nochmal klar machen dass man mit der freien Lösung auch das meiste — wenn nicht alles — hinkriegt. :-D

Nachtrag: Momentan stört mich das nicht, aber wer das im großen Stil einsetzen will sollte vielleicht noch was einbauen das dafür sorgt dass auch etwas sinnvolles passiert wenn der Host offline ist, aber noch keine Daten dafür im Cache liegen…