Die Schatenseite

Das Zabbix-Item

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…