Zabbix unsupported Items

Unsupported Items überwachen

Leicht macht man bei der Konfiguration einen Fehler. Man richtet ein Item und einen Trigger ein, doch das Betriebssystem stellt die gewünschten Daten gar nicht zur Verfügung.

Nun verlässt man sich auf sein Monitoring und wiegt sich in Sicherheit. Der eingerichtete Trigger schlägt ja keinen Alarm.

Das Dashboard zeigt an, wie viele Items nicht ausgewertet werden können (Unsupported Items).

Zabbix wertet die Trigger in dem Moment aus, in dem die Daten eines Items den Server erreichen. Wenn nun das Item aber keine Daten liefert, weil es zum Beispiel nicht existiert, dann wird der Trigger niemals ausgeführt. Folglich wird es auch keinen Alarm geben.

Eine Ausnahme zur eben beschrieben Auswertung von Daten stellt die Trigger-Funktion nodata() dar. Diese wird auch angewendet, wenn ein Item keine Daten liefert. Nun könnten Sie für alle Items immer einen Trigger mit nodata() einrichten, um Sicher zu gehen, dass Sie bei der Konfiguration der Items keinen Fehler gemacht haben.

Eine einfache Möglichkeit, Items aufzuspüren, die keine Daten liefern, bieten die "Zabbix-Internal Checks".
Das Item "zabbix[items_unsupported]" liefert Ihnen die Zahl der Items zurück, die aktuell keine Daten liefern.

Richten Sie sich also dieses Item ein, setzten Sie einen Trigger, der Sie alarmiert, sobald Items als "unsupported" deklariert werden. (zabbix[items_unsupported]>0)

Sobald die Anzahl der Unsuppored Items größer Null ist, haben Sie einen Fehler in der Konfiguration.

Legen Sie für den Zabbix-Server ein Item und einen Trigger an, welche die Anzahl der unsupported Items auswerten.
Der Grund für ein "Unsuppoted Item" muss nicht immer in der Konfiguration des Items auf dem Zabbix-Server liegen. Besonders bei User-Parametern können ein Fehler im Zabbix-Agenten oder fehlende Rechte die Ursache sein.

Aktionen bei fehlerhaften Items ausführen

Der Zabbix-Server kann Sie sofort informieren, sobald ein Item in den Status „unsupprted“ wechselt. Auf der Weboberfläche können Sie unter Configuration|Action rechts oben als „Event Source“ „Internal“ auswählen. Es sind bereits drei Regeln hinterlegt, welche aber alle deaktiviert sind. Wenn Sie sich die Regel „Report not supported items“ genauer ansehen, finden Sie dort „Item in not supported state“ als Event-Auslöser vor. Sobald ein Item diesen Status annimmt, wird eine Nachricht an alle Zabbix-Administratoren geschickt. Sie können diese Aktion wie jede andere Aktion Ihren Bedürfnisse anpassen. In den meisten Fällen erfüllt die Standard-Aktion aber ihren Zweck. Sie müssen diese lediglich aktivieren.

Zabbix benachrichtigt, wenn Items fehlerhaft sind.

Mehr Informationen über Unsupported Items

Im Logfile des Zabbix-Server finden Sie detaillierter Informationen, welche Items fehlerhaft sind und keine Daten liefern. Sollten dort keine Einträge wie unten beispielhaft aufgelsitet, müssen Sie das sogenannten „Debug-Level“ in der Datei zabbix_server.conf auf 3 oder 4 erhöhen.

Lassen Sie den Zabbix-Server nicht dauerhaft im Debug-Level 4 laufen. Verringern Sie das Level sobald Sie die Fehleranalyse abgeschlossen haben.

Mit folgendem Kommando sehen Sie, für welche Items und Hosts Zabbix keine Daten abrufen kann.

grep -o "Item.*Not supported by Zabbix-Agent" /tmp/zabbix_server.log|sort -u

Sie erhalten eine Ausgabe, ähnlich wie diese:

Item [accounting.example.int:system.cpu.util[,idle,avg5]] error: Not supported by Zabbix
Item [exchange.example.int:system.cpu.util[,idle,avg5]] error: Not supported by Zabbix A
Item [fileserver_wiesbaden:system.cpu.util[,idle,avg5]] error: Not supported by Zabbix A
Item [gate1.example.int:vfs.fs.size[c:,pfree]] error: Not supported by Zabbix-Agent
Item [monitoring.example.de:mysql.global_status[Max_used_connections]] error: Not suppor
Item [monitoring.example.de:mysql.variables[max_connections]] error: Not supported by Za
Item [monitoring.example.de:net.if.in[eth0]] error: Not supported by Zabbix-Agent
Item [monitoring.example.de:net.if.out[eth0]] error: Not supported by Zabbix-Agent
Item [monitoring.example.de:system.run[/bin/uname -r]] error: Not supported by Zabbix Age
Item [monitoring.example.de:vfs.file.cksum[/opt/noexistent]] error: Not supported by Zabb
Item [mxsync.example.int:system.cpu.util[,idle,avg5]] error: Not supported by Zabbix Agen
Item [example-nas.test.de:system.run[/bin/uname -r]] error: Not supported by Zabbix-Agent
Item [example-nas.test.de:system.swap.size[,used]] error: Not supported by Zabbix-Agent
Item [sql01.example.int:mysql.questions] error: Not supported by Zabbix-Agent
Item [sql01.example.int:system.run[/bin/uname -r]] error: Not supported by Zabbix-Agent
Item [sql03.example.int:system.run[/bin/uname -r]] error: Not supported by Zabbix-Agent
Item [syslog.example.int:system.run[/bin/uname -r]] error: Not supported by Zabbix-Agent
Item [web01.example.int:vfs.fs.size[c:,pfree]] error: Not supported by Zabbix-Agent

Unsupported Items über die API ermitteln

Die eingebaute Eventquelle „Item in state not supported“ ist sehr nützlich, um Aktion bzw. den Versand von Nachrichten auszulösen. Wenn Sie aber mehrere Tausend Hosts mit mehr als 10.000 Items überwachen, wollen Sie vielleicht nicht in Ihrem Postfach nachschauen, um die aktuelle Liste der fehlerhaften Items zu prüfen.
Praktischer wäre es doch, wenn jeder Host in einem eigenen Items die Liste und Anzahl der fehlerhaften Items speichern würde. Dann könnten Sie auf dieses Item einen Trigger setzen. Außerdem können Sie dann über die Filter in „Latest Data“ eine übersichtliche Liste generieren. Vielleicht haben Sie ja einen großen Bildschirm im Büro, der alle aktiven Trigger anzeigt. Dieser würde die fehlerhaften Items automatisch anzeigen, wenn Sie diese über einen Standard-Trigger auswerten könnten. Mit der Zabbix-API ist dies kein Problem.
Mit einem kleinen Python-Skript, welches als „externer Check“ eingebunden wird, rufen Sie pro Host die Liste der fehlerhaften Items ab und speichern diese in einem neuen Item ab.

Installieren Sie das Zabbix-Python-Modul. Dazu können Sie den Python-Paketmanager „Pip“ verwenden. Benutzer von CentOS und Red Hat benötigen dazu das sogenannte EPEL-Repository:

apt-get install python-pip # Debian, Ubuntu
yum -y install python-pip  # CentOS, Red Hat
pip install pyzabbix

Laden Sie das Python-Skript unsupported_items herunter und kopieren Sie es auf dem Zabbix-Server in den Ordner für „external Scripts“. Machen Sie dieses ausführbar und öffnen Sie die Datei mit einem Editor. In den ersten Zeilen tragen Sie einen Benutzer und ein Kennwort ein, mit dem die Zabbix-Api abgefragt wird. Der Benutzer sollte mindestens über Leserechte für alle Hosts verfügen.

Abfrage der Zabbix-API nach fehlerhaften Items pro Host.

Testen Sie anschließend das Skript mit einem Host, der über fehlerhafte Items verfügt und mit einem Host, der fehlerfrei überwacht wird:

./unsupported_items lab4.org
Host has 1 unsupported items.
  An error with intent (23705): Unsupported item key.
./unsupported_items "Zabbix Server"
No unsupported items.

Jetzt können Sie ein Template anlegen, welches mit einem externen Check und dem Item-Key unsupported_items[{HOST.NAME}] ausliest, ob der entsprechende Hosts fehlerhaft überwacht wird. (Type of Information = Text)

Zabbix-Server fragt seine eigene API, ob ein Hosts „unsupported Items“ meldet.

Basierend auf diesem Item richten Sie einen Trigger ein, der mit dem Ausdruck str(No unsupported items)}=0 ein Problem meldet, sobald die API etwas anderes sagt, als „No unsupported items“.

Dieses Skript funktioniert nur für Hosts, welche ohne Proxy überwacht werden. Sobald ein Host per Proxy überwacht wird, werden auch die externen Checks auf dem jeweiligen Proxy ausgeführt. Kopieren Sie das Skript auch auf die Proxys und passen Sie im Skript die URL der Zabbix-API an.