Zabbix effizientes Arbeiten mit Templates

Effiziente Konfigurationen mit Templates

Templates sind Vorlagen, die aus einem Set von Items, Triggern und Graphen bestehen. Seit der Version 2.0 können auch Screens und sogenannte Discovery Rules in Vorlagen hinterlegt werden.
Sie müssen nicht für jeden Hosts immer die gleichen Items und Trigger anlegen. Sie definieren eine Konfiguration (Item, Trigger, evtl. Graphen und Screens) einmal in einem Template und weisen dann dem Host die passenden Templates zu. Das erspart zum einen Arbeit und hält die Konfiguration zum anderen konsistent.

Wenn Sie mehr als einen Host mit Zabbix überwachen, dann sollten Sie den Großteil der Konfiguration in Templates abbilden. Arbeiten Sie nach der bekannten DRY-Regel der Programmierer. Don't repeat yourself! Für Zabbix bedeutet das, dass Sie Konfigurationsschritte nicht doppelt vornehmen sollten.

Angenommen, Sie überwachen für einen Linux-Host den Füllstand der Festplatte, und über einen Trigger lösen Sie beim Unterschreiten eines Wertes Alarm aus. Nun kommt der nächste Server in Ihr Netzwerk, und bei diesem Host soll der Festplattenzustand wie beim ersten Host überwacht werden. Dann ist es Zeit, die Konfiguration in ein Template zu verlagern. Beide Hosts verwenden dann dasselbe Template.

Die mitgelieferten Standardtemplates

Wenn Sie ein Template in der Gruppe „Templates“ anlegen, stellen Sie fest, dass in dieser Gruppe bereits viele Templates vorhanden sind. Dies sind Beispiele, die fester Bestandteil von Zabbix sind.

Diese Templates sollen die Möglichkeiten von Zabbix verdeutlichen. Nutzen Sie die Beispiele, um sich abzuschauen, wie man spezielle Hard- und Software monitoren kann. Für den produktiven Einsatz sind diese Templates nicht oder nur sehr eingeschränkt zu empfehlen. Pro Templates sind oft mehr als 100 Items und Trigger hinterlegt. In den seltensten Fällen wollen Sie diese Menge an Informationen sammeln. Außerdem würde das Anwenden eines Beispieltemplates zu zahlreichen Fehlalarmen führen, weil die Beispiele Systembereiche überwachen, die bei Ihnen wahrscheinlich nicht vorhanden sind.

Schauen Sie sich die Beispiele an und übernehmen Sie dann gezielt einzelne Items und Trigger in Ihre eigenen Templates.

Wenn Sie Ihre eigenen Templates auch in der Gruppe Templates ablegen wollen, dann sollten Sie die Gruppe mit den Beispielen vorher umbenennen. Klicken Sie auf Configuration|Host groups und nennen Sie die Gruppe Templates zum Beispiel Templates Zabbix Examples.

Templates anlegen

Templates werden über das Hauptmenü Configuraton|Templates angelegt. Wie gewohnt befindet sich oben rechts der Knopf „Create Template“. Templates können wie Hosts in Gruppen sortiert werden. Sie müssen Ihre Templates nicht in die Gruppe „Templates“ packen. Die Gruppen können beliebige Namen tragen.

Geben Sie den Templates einen aussagekräftigen Namen. Es kann hilfreich sein, wenn Sie im Namen des Templates schon angeben, ob die enthaltenen Items auf den Zabbix-Agenten angewiesen sind oder ob es rein passive Checks sind. So könnten Templates zum Beispiel „Base Availability (Passiv)“ oder „Base Availability (Agent)“ heißen. Solche Angaben erleichtern später das Auffinden eines passenden Templates, wenn Sie einen neuen Host anlegen.

Über das Auswahlmenü „Hosts in Template“ wenden Sie ein neu angelegtes Template sofort auf Hosts an. Sie können diese Liste auch leer lassen und später über die Konfiguration der Hosts auswählen, welche Templates ein Host verwenden soll.

Anlegen eines neuen Templates

Über den Reiter (Linked Templates) können Sie Templates verschachteln. Das bedeutet, ein Template kann Konfigurationen aus anderen Templates verwenden. Nutzen Sie diese Möglichkeit, um doppelte Konfigurationen zu vermeiden. Wenn Sie ein Paar aus Item und Trigger in mehreren Templates verwenden möchten, dann legen Sie für dieses Item-Trigger-Paar ein eigenes Template an. Dieses Template können Sie dann in anderen Templates verwenden, so dass keine Items oder Trigger doppelt angelegt werden. Siehe auch die Beispiele am Ende dieses Kapitels.

Sobald Sie ein Template angelegt haben, finden Sie es in der Liste der Templates wieder. Zum Hinzufügen von Items, Triggern, Graphs etc. klicken Sie in der Liste auf den entsprechenden Link in der Zeile des Templates. Die Konfiguration erfolgt analog zur Konfiguration eines Hosts. Statt eines Hostnamens enthalten die Items den Namen des Templates.

Beim Anlegen eines Triggers für ein Template müssen Sie Acht geben. Bei der Auswahl des Items für einen Trigger können Sie sowhl ein Host-Item als auch ein Template-Item verwenden. Host-Items sind die vom Template an den Host vererbten Items. Achten Sie darauf, dass Sie die Trigger in Templates immer für die Templates-Items anlegen. Die Trigger-Expression muss immer mit dem Namen des Templates beginnen.

Definition eines Triggers innerhalb eines Templates. Die Trigger-Expression beginnt nicht mit einem Hostnamen, sondern dem Namen des Templates.

Beispiel: Ping-Check-Template

Lassen Sie sich über Configuration|Templates die Liste aller Templates anzeigen. Klicken Sie oben rechts auf Create Template und tragen Sie die nachfolgenden Werte ins Formular „Template“ ein. Die Formulare auf den Reitern „Linked Templates“ und „Macro“ füllen Sie nicht aus.

  • Template name: Passive Ping Check
  • New Group: My own templates
  • Description: Check if host responds to pings and rise action if not.
Anlegen eines neuen Templates

Nach dem Speichern wählen Sie in der Liste der Templates oben rechts die neu angelegte Gruppe „My own templates“ aus. Sie sehen nun, dass dieses Template noch über keine Items und Trigger verfügt. Klicken Sie auf den Link Items (0) und anschließend oben rechts auf Create item. Nun legen Sie wie gewohnt ein Item mit folgenden Parametern an:

  • Name: ICMP Ping Check
  • Type: Simple Check
  • Key: icmpping
  • Type of information: Numeric (unsigned)
  • Update Interval (in sec): 30
  • New Application: Availability PASSIV

Nachdem Sie das Item gespeichert haben, klicken Sie oberhalb der Tabelle auf den Link Triggers (0) und legen mit dem Button oben rechts Create trigger einen neuen Trigger mit den folgenden Parametern an:

  • Name: No Ping to host
  • Expression: {Passive Ping Check:icmpping.last()}=0
  • Severity: Average

Wenn Sie den Trigger angelegt haben, werfen Sie noch einmal einen Blick auf die tabellarische Übersicht der Templates in der Gruppe „My own templates“. Sie sollten nun sehen, dass das Template „Passive Ping Check“ über ein Item und einen Trigger verfügt. Damit ist die Einrichtung des Templates abgeschlossen.

Wählen Sie nun über Configuration|Hosts eine Hostgruppe aus und klicken Sie auf den Namen eines Hosts. Wählen Sie den Reiter „Templates an“. Im Eingabefeld „Link new templates“ geben Sie den Namen des zuvor erstellten Templates ein: „Passive Ping Check“. Mit dem kleinen Link Add unterhalb des Templatenamens weisen Sie nun das Template dem Host zu. Speichern Sie die geänderte Host-Konfiguration mit der Schaltfläche „Save“. Sie gelangen zurück in die tabellarische Übersicht der Hosts. Nun sollten Sie sehen, dass der Host ein Item und einen Trigger mehr hat. In der Spalte „Templates“ sollte das soeben angewandte Template verzeichnet sein.

Templates individualisieren mit Makros

Die Verwendung von Makros gibt Ihnen die Möglichkeit, die Regeln eines Templates für einzelne Hosts zu individualisieren. Makros sind Variablen, die an die Hosts vererbt, aber an verschiedenen Stellen überschrieben werden können.

Beispiel 1: Makros in Items

Definieren Sie über Administration|General|Macros zum Beispiel {$SSH_PORT} = 22 als globales Makro. Danach legen Sie ein Item vom Typ Simple Check an: net.tcp.service[ssh,,{$SSH_PORT}]. Wenn nun ein Host den SSH-Dienst nicht an den Port 22 bindet, geben Sie für den entsprechenden Hosts das Makro {$SSH_PORT} an und überschreiben den Standard.

Verwendung eines Makros in einem Item

An folgenden Stellen können Sie Makros definieren:

  • globale Makros, gelten für alle Bereiche, Hosts und Templates (niedrigste Priorität)
  • Templates
  • Host (höchste Priorität)

Beispiel 2: Makros in Triggern

Sie legen zum Beispiel ein Template mit einem Trigger an, der bei weniger als 2GB freien Festplattenplatz alarmiert. Für den Großteil Ihrer Hosts passt diese Regel. Nun gibt es aber auch Hosts, bei denen schon bei weniger als 5GB alarmiert werden soll. Sie brauchen keine getrennten Templates anlegen. Makros sind die Lösung.
Definieren Sie im Template über den Reiter Makros zum Beispiel ein Makro {$MIN_FREE_SPACE} mit dem Wert 2. Dieser Wert ist der Standardwert für alle Hosts, die das Template verwenden.

Template mit einem Makro

Legen Sie nun ein Item und einen Trigger an, wobei Sie in der Trigger-Expression das Makro als Vergleichswert verwenden.

{disk usage:vfs.fs.size[/,free].last(0)}<{$MIN_FREE_SPACE}*1024*1024*1024

Im Makro {$MIN_FREE_SPACE} geben Sie an, welchen Füllstand in GB die Festplatte nicht unterschreiten darf.

Trigger mit Makro

Wenn nun für einige Hosts ein abweichender Wert für {$MIN_FREE_SPACE} verwendet werden soll, überschreiben Sie das Makro in der Konfiguration des Hosts. Die Angaben auf Host-Ebene haben eine höhere Priorität als die Angaben auf Templateebene.

Beispiel 3: Makros in Aktionen

Legen Sie in der Host-Konfiguration über den Reiter Makros die beiden Makros {$ROOM_NO} und {$RESPONSIBLE_PERSON} an und tragen Sie ein, in welchem Raum sich der Server befindet und welche Person für das Gerät verantwortlich ist.

Pro Host hinterlegen Sie in Makros Informationen für die schnellere Bearbeitung von Störungen.

Wechseln Sie nun über das Menü Configuration|Actions in die Einstellungen einer beliebigen Aktion. Fügen Sie dann zum Beispiel in der Standardnachricht den folgenden Textblock ein:

Server located in room {$ROOM_NUMBER}
Please contact {$RESPONSIBLE_PERSON}
Missbrauchen Sie die Makros nicht, um eine komplette Inventarverwaltung zu pflegen. Zabbix hat eine umfangreiche Inventarverwaltung an Bord. Mit dieser können Sie Zusatzinformationen zu Hosts und Geräten strukturiert erfassen.

Templates strukturieren

Es ist nicht ratsam, viele Items in wenige Templates zu konfigurieren. Legen Sie besser viele Templates an, die nur wenige Items enthalten. Das gibt Ihnen mehr Flexibilität.

Legen Sie Simple Checks und Agent Checks nach Möglichkeit nicht in ein Template. Geben Sie im Templatenamen an, ob das Template den Zabbix-Agenten voraussetzt. Je mehr Hosts Sie überwachen, desto häufiger wird es Ihnen nicht möglich sein, den Zabbix-Agenten zu installieren. Deshalb ist es sinnvoll, ein Set an Templates vorzuhalten, die keinen Agenten brauchen. Wenn Sie ein Template für Linux-Hosts anlegen, sollten Sie den Check, ob der SSH-Server Verbindungen akzeptiert, nicht mit den Festplattenchecks im selben Template anlegen.

Legen Sie betriebssystemunabhängige Items nicht mit betriebssystemspezifischen Items in ein Template. Items wie zum Beispiel das Prüfen der Systemzeit funktionieren unter allen Betriebssystemen gleich. Würden Sie dieses Item zum Beispiel in ein Template „Linux“ einbinden, dann müssten Sie dieses Item doppelt anlegen, wenn Sie ein Template für Windows-Systeme anlegen.

Eine Beispielstruktur:

Beispielstruktur für Templates
Template Checks
Base Availability (agentless) ICMP Ping
Base Availability (agent) agent.ping
Base osindipendend (agent) system.boottime, system.hotsname, system.localtime
Linux (agentless) ssh
Windows (agentless) tcp,3389
Linux (agent) system.cpu.util, vfs.fs.size, net.if.in, net.if.out etc.
Windows (agent) vfs.fs.size, perf_counter[\Speicher\Verfügbare Bytes], perf_counter[\Prozessor(_Total)\Prozessorzeit (%)], etc.
MySQL (agentless) tcp,3306
MySQL (agent) mysql.ping, mysql,queries etc.
Linux (combined) Base Availability (agentless)+Base Availability (agent)+Base osindipendend (agent)+Linux (agentless)+Linux (agent)
Windows (combined) Base Availability (agentless)+Base Availability (agent)+Base osindipendend (agent)+Windows (agentless)+Windows (agent)
Templatestruktur mit verschachtelten Templates

Hostspezifische Items automatisch erzeugen (Low Level Discovery)

Mit der Version 2.0 wurde eine neue Funktion namens Low Level Discovery in Zabbix aufgenommen. Eine Discovery-Regel entdeckt zum Beispiel alle verfügbaren Festplatten eines Hosts und erzeugt dann Items, die alle entdeckten Festplatten überwachen.

Nachfolgend wird die Funktionsweise der Low Level Discovery mit dem Zabbix-Agenten oder dem Zabbix-Trapper erklärt. Low Level Discovery ist auch per SNMP möglich, welches im Kapitel SNMP erklärt wird.

Das automatische Hinzufügen hostspezifischer Items geschieht in zwei Schritten. Der erste Schritt ist die sogenannte Discovery Rule. Diese Regel ist letztendlich ein „normales“ Item, welches aber nicht einen einzelnen Wert, sondern eine Liste mit Werten enthält. Diese Liste wird im Format JSON gespeichert. Diese Liste kann von jeder Quelle generiert werden, die als Item-Typ zur Verfügung steht. In der Regel wird diese Liste vom Zabbix-Agenten generiert und listet Hardwarekomponenten auf. Im Zabbix-Agent ab Version 2.0 sind die beiden Items vfs.fs.discovery und net.if.discovery integriert, welche die verfügbaren Festplatten und Netzwerkkarten auflisten.

Verdeutlichen Sie sich die Funktionsweise einer Discovery-Regel und das Format der zurückgelieferten Liste, indem Sie auf einem Host den Wert des Items vfs.fs.discovery auf der Konsole ausgeben lassen.

root@zabbix:~# zabbix_agent -t vfs.fs.discovery
vfs.fs.discovery                              [s|{
    "data":[
        {
            "{#FSNAME}":"\/",
            "{#FSTYPE}":"rootfs"},
        {
            "{#FSNAME}":"\/sys",
            "{#FSTYPE}":"sysfs"},
        {
            "{#FSNAME}":"\/proc",
            "{#FSTYPE}":"proc"},
        {
            "{#FSNAME}":"\/dev",
            "{#FSTYPE}":"devtmpfs"},
        {
            "{#FSNAME}":"\/dev\/pts",
            "{#FSTYPE}":"devpts"},
        {
            "{#FSNAME}":"\/run",
            "{#FSTYPE}":"tmpfs"},
        {
            "{#FSNAME}":"\/",
            "{#FSTYPE}":"ext4"},
        {
            "{#FSNAME}":"\/run\/lock",
            "{#FSTYPE}":"tmpfs"},
        {
            "{#FSNAME}":"\/run\/shm",
            "{#FSTYPE}":"tmpfs"},
        {
            "{#FSNAME}":"\/var",
            "{#FSTYPE}":"ext4"},
        {
            "{#FSNAME}":"\/var\/lib\/mysql",
            "{#FSTYPE}":"ext4"}]}]

Damit der Zabbix-Server für jeden Eintrag einer Liste später ein Item erzeugt, muss ein sogenannter Prototyp eingerichtet werden. Der Prototyp ist ein Item, bei dem die Elemente der Liste als Makros verwendet werden, zum Beispiel vfs.fs.size[{#FSNAME},free]. Für jedes Element der Liste erzeugt der Zabbix-Server ein neues Item.

Nachdem Sie eine Discovery-Regel angelegt haben, legen Sie die Items nicht für das Template, sondern für die Discovery-Regel an.

Liste der Discovery-Regeln
Interner Ablauf der Low-Level-Discovery

Beispiel 1: Dateisysteme erkennen

Im nachfolgenden Beispiel erfahren Sie, wie Sie ein Item in einem Template einrichten, so dass alle in einem Host verfügbaren Dateisysteme (Festplatten) automatisch überwacht werden.

Wählen Sie über das Hauptmenü Configuration|Templates aus. In der tabellarischen Übersicht der Templates klicken Sie hinter einem Template auf den Link Discovery. Sie sehen die Liste der Discovery-Regeln für das Template. Klicken Sie oben rechts auf die Schaltfläche Create Rule.

Legen Sie eine Regel vom Typ „Zabbix-Agent“ an, als Item-Key verwenden Sie vfs.fs.discovery. Der Zabbix-Server fragt dann alle Hosts nach einer Liste der verfügbaren Dateisysteme. Diese Liste enthält neben den Pfaden zu den Mountpoints auch den Dateisystemtyp. Sofern Sie die Dateisysteme wie /proc, /dev etc. nicht überwachen wollen, geben Sie als Filter auf das Makro {#FSTYPE} den Regulären Ausdruck ext[3,4]|xfs an. Es werden nur die Einträge aus der zurückgelieferten Liste verwendet, für die die Filterregel zutrifft.

Da sich die Dateisysteme in einem Host in der Regel nicht sehr häufig ändern, sollten Sie das Update-Intervall auf 3600 Sekunden einstellen. Zum Testen der Funktionsweise von Discovery-Regeln können Sie, bis alles zufriedenstellend läuft, auch 30 Sekunden wählen.

Regeln zum Auslisten aller Dateisysteme eines Hosts in Zabbix 3
Ab Version 2.4 können mehrere Filter auf das Resultat einer Discovery-Regel angewendet werden

Nachdem Sie die neue Regel gespeichert haben, sehen Sie die Liste aller Discovery-Regeln. Klicken Sie in der Zeile der zuvor angelegten Regel auf den Link Items, und über den Knopf oben rechts legen Sie ein neues Item an.
Sie legen nun wie gewohnt ein Item an. Sobald Sie im Item-Key das Makro {#FSNAME} verwenden, wird das Item für jedes gefundene Dateisystem angelegt.

Item basierend auf einer Discovery-Regel anlegen


Dateisystem ausschließen

Möchten Sie Dateisysteme von der automatischen Erkennung ausschließen, müssen Sie einen kleinen Umweg über vordefinierte Reguläre Ausdrücke gehen. In den Filtern der Discovery Regeln können keine Negierungen von Regulären Ausdrücken verwendet werden (Lookarround, Lookahead ist nicht möglich).

Legen Sie zuerst einen vordefinierten Regulären Ausdruck in der globalen Konfiguration an und verwenden Sie diesen als zusätzlichen Filter.

Ausschluss von Mountpoints

Beispiel 2: Netzwerkgeräte automatisch hinzufügen

Zum automatischen Hinzufügen von Netzwerkkarten verfahren Sie ähnlich wie bei den Festplatten. Legen Sie eine Discovery-Regel an, welche über den Zabbix-Agenten und den Item-Key net.if.discovery alle auf dem Host verfügbaren Netzwerkkarten auslistet. Wenn Sie das Loopback-Interface nicht ins Monitoring aufnehmen möchten, verwenden Sie einen Filter auf das Makro {#IFNAME}.

Der Zabbix-Agent listet alle Netzwerkgeräte auf.

Richten Sie für die zuvor erstelle Discovery-Regel zwei Items mit den Item-Keys net.if.in[{#IFNAME}] und net.if.out[{#IFNAME}].

Netzwerkkarten werden automatisch erkannt und gemonitort.

Wenn Sie einen Graphen für eine Discovery-Regel anlegen, muss das Makro der entdeckten Elemente im Namen des Graphen vorkommen.

Graph basierend auf einer Discovery-Regel

Nachdem Sie das Template mit den Discovery-Regeln auf einen Host angewendet haben, sollte der Zabbix-Server diesem Host neue Items hinzufügen. Wenn Sie im Hauptmenü Configuration|Hosts auswählen und in der Zeile eines Hosts auf den Link Items klicken, sehen Sie die automatisch hinzugefügten Items. Dass diese Items von einer Discovery-Regel stammen, erkennen Sie an dem in Gelb vorangestellten Namen der Regel.

Items, welche automatisch zu einem Host hinzugefügt wurden.
Items, die auf Elementen basieren, die von einer Regel nicht mehr gefunden werden, zum Beispiel Dateisysteme, die ausgehängt wurden, entfernt der Zabbix-Server nicht. Es werden nur neu entdeckte Elemente hinzugefügt. Von einer Discovery-Regel gefundene, aber nicht mehr vorhandene Elemente können Sie nur entfernen, indem Sie das entsprechende Template mit „Unlink and Clear“ entfernen und dann wieder neu hinzufügen.

Eigene Discovery-Regeln erstellen

Sie können auch eigene Discovery-Regeln erstellen. Das nachfolgende Beispiel durchsucht die Konfigurationsdateien des Apache-Webservers und listet alle Domänennamen der virtuellen Hosts auf. Sie können dann jeden virtuellen Host vom Zabbix-Server per HTTP-Anfrage überwachen.

#!/usr/bin/perl
$first = 1;
print "{\n";
print "\t\"list.vhosts\":[\n";

for (`grep -h " ServerName" /etc/apache2/vhosts.d/*`)
{
    ($host) = m/ServerName\s+(.*)/;
    print ",\n" if not $first;
    $first = 0;
    print "\t{ \"{#HOST}\":\"$host\" }";
}

print "\n\t]\n";
print "}\n";

Passen Sie ggf. den Ordner an, in denen das Skript die Konfigurationsdateien sucht. Machen Sie das Skript ausführbar und testen Sie es. Es sollte eine ähnliche Ausgabe wie die folgende produzieren:

{
    "list.vhosts":[
    { "{#HOST}":"dummy-host.example.com" },
    { "{#HOST}":"www.mywebsite.com" },
    { "{#HOST}":"www.myblog.com" }
    ]
}

Registrieren Sie dieses Skript im Zabbix-Agenten als User-Parameter, zum Beispiel:

UserParameter=list.vhosts,/etc/zabbix/scripts/list.vhosts.pl

Massendaten verarbeiten (Dependent items)

Mit Zabbix 3.4 wurde die Verarbeitung von Massendaten erheblich vereinfacht und effizienter gemacht. Ein Item kann mehrere Messwerte zurück liefern, welche vom Zabbix-Server in einzelne Items gespeichert werden.

Eine MySQL Datenbank kann mit einer einzelnen Query SHOW GLOBAL STATUS den gesamten Status reporten. Vor Zabbix 3.4 konnte ein Item immer nur einen Wert liefern. Um den Status der Datenbank abzufragen, musste der Zabbix-Server einzelne Items abfragen, welche dann Queries ausführten, die nur einen Wert lieferten, z.B. SHOW GLOBAL STATS LIKE 'Com_select'.

Seit Zabbix 3.4 kann ein Master-Item mehrere Werte liefern. Das Master-Item liefert eine Liste mit Werten im Textformat. Sobald sich das Master-Item aktualisiert, "zerlegt" der neu eingeführte Preprocessing Manager in einzelne Items. Das Master-Item kann die Messwerte in strukturierter Form abliefern, hier stehen Json und XML zu Verfügung. Das Einliefern unstrukturierter Daten in einem beliebigen Format ist ebenfalls möglich, der Preprocessing Manager kann mit Regulären Ausdrücken einzelne Werte extrahieren.

Beispiel MySQL Status

Legen Sie einen neuen UserParameter für den Zabbix-Agenten an:

UserParameter=mysql.global-status,/usr/local/bin/mysql-global-status.py

Die Datei /usr/local/bin/mysql-global-status.py enthält ein kleines Skript, welches die Rückgabe einer SQL-Query als Json-Objekt zurück liefert.

#!/usr/bin/python

#
# yum install MySQL-python
# apt-get install python-mysqldb
# grant REPLICATION CLIENT on *.* to zabbix@localhost identified by 'zabbix';
#

import MySQLdb
import json
mysql_opts = {
    'host': "localhost",
    'user': "zabbix",
    'pass': "zabbix",
    }
mysql = MySQLdb.connect(mysql_opts['host'], mysql_opts['user'], mysql_opts['pass'])
cursor = mysql.cursor()
cursor.execute("SHOW GLOBAL STATUS LIKE 'Com_%'")
status = cursor.fetchall()
result = {}
for row in status:
    result[row[0]] = row[1]

print json.dumps(result)

Legen Sie das Master-Item an. Eine lange Speicherdauer des Master-Items ist in der Regel nicht notwendig, da die enthaltenen Werte nach dem "Zerlegen" noch einmal in den einzelnen Unter-Items gespeichert werden.

Ein Master-Item, welche mehrere Messwerte liefert.

Legen Sie die sogenannten "abhängigen Items" an. Type des Items ist "Dependet Item". Ein Update-Intervall können Sie nicht festlegen, dieses wird vom Master-Item festgelegt. Sobald neue Messwerte vom Master-Item eingeliefert werden, werden alle abhängigen Items aktualisiert. Den Item-Key vergeben Sie frei. Über den Button "Select" wählen Sie das Master-Item aus, welche die Messwerte liefert.

Ein abhängiges Items speichert einen Wert aus einem Master-Item.

Über den Reiter "Preprocessing" wählen Sie aus, welcher Wert aus dem Json-Object des Master-Items extrahiert wird. Achten Sie auch auf die Art der Speicherung "Change per second". MySQL liefert im Wert "Com_select" einen ständig steigenden Zähler, mit den seit Serverstart ausgeführten Selects. Mit der Speicherung als "Change per second" wird die Differenz zwischen den einzelnen Messwerten gespeichert, und durch das Zeitintervall zwischen den Messungen geteilt.

Extraktion eines Wertes aus einem Json-Objekt.
Achten Sie darauf, dass die Schlüssel des Json-Objektes keine Leerzeichen enthalten. Dies ist laut Json-Spezifikation zwar zulässig, der Zabbix-Server kann aber keine Werte aus Json-Objekte extrahieren, wenn der Schlüssel Leerzeichen enthält.

Beispiel OracleDB Status

Analog zum MySQL-Beispiel können Sie den Status einer Oracle-Datenbank über eine einzige Query auslesen und über ein Master-Ietm als Json-Objekt an den Zabbix-Server schicken. Ein Skript zum Abrufen des Status könnte wie folgt aussehen:

#!/usr/bin/python

import cx_Oracle
import json

try:
  db = cx_Oracle.connect("zabbix/zabbix@127.0.0.1")
  cursor = db.cursor()
  cursor.execute("select name,value from v$sysstat")
  ret = {}
  for row in cursor:
    key = row[0].replace(" ","_")
    ret[key] = str(row[1])
  print json.dumps(ret)

except cx_Oracle.DatabaseError, e:
  error, = e.args
  print >> sys.stderr, "Oracle-Error-Code:", error.code
  print >> sys.stderr, "Oracle-Error-Message:", error.message

finally:
  cursor.close()
  db.close()

Der passende UserParameter könnte der Folgende sein:

UserParameter=oracle.sysstat,ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe /var/lib/zabbix/oracleSysStat.py
Achten Sie darauf, dass vor dem Ausführen des Skriptes ORACLE_HOME gesetzt wird, da der Zabbix-Agent keine Umgebungsvariablen lädt.