by ·3 Kommentare

Ich glaube ich erwähnte es schon: eines meiner Steckenpferde bei der Arbeit ist das Monitoring, also die Überwachung von Rechnern. Bei bestimmten Überwachungen bietet es sich an, den überwachten Rechner seine Messwerte selbst schicken zu lassen. Oft heißt es „es reicht wenn wir den Wert alle fünf Minuten kriegen“, also bietet sich ein Cronjob mit einem geschickt platzierten „*/5“ an.

Nachteil dabei: unter Umständen wird das Monitoring genau alle fünf Minuten zeitgleich mit hunderten Werten von hunderten Rechnern beworfen.

Um das zu entzerren habe ich mir was formschönes ausgedacht:

Diese Zeile bewirkt am Anfang eines Skriptes, dass vor der Ausführung eine variable Zeit gewartet wird. Das charmante daran: die Zeit ist abhängig vom Hostnamen, dem Skriptnamen und den Parametern die dem Skript übergeben werden. Es ist keine wirklich zufällige Zeit, das heißt dass man sich darauf verlassen kann dass das Skript ziemlich genau alle fünf Minuten einen Wert ausgibt.

Oh, falls das cut irritiert: wenn ich die hexadezimale Prüfsumme einfach mit $((0x…)) dezimal mache kommt da unter Umständen ein negativer Wert raus. Meine sleep-Version unterstützt leider keine Zeitreisen… ;-)

Hat jemand einen Vorschlag wie ich das noch eleganter hinkriegen würde?

EDIT: Vielleicht ist diese Variante noch schöner. Man umgeht mit Awk den ‚bashismus‘ mit dem Modulo, dafür spart man sich aber auch den Aufruf von cut.

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…