Zabbix Items Daten per Agent sammeln

Was ist der Zabbix-Agent?

Über den Zabbix-Agenten kann der Zabbix-Server so gut wie jede Information eines Hosts abrufen und zur Weiterverarbeitung speichern.

Der Zabbix-Agent ist für fast alle Betriebssysteme verfügbar. Erst durch den Einsatz des Agenten kann Zabbix seine ganze Stärke zeigen. Mit Simple Checks können Sie zwar entdecken, dass ein Dienst oder Host nicht mehr verfügbar ist. Um detaillierte Informationen zu erhalten, warum es zu einem Fehler gekommen ist, brauchen Sie zusätzliche Daten. Diese können Sie mit Simple-Checks in der Regel nicht messen. Hier kommt der Zabbix-Agent ins Spiel. Ein präzises Monitoring braucht Informationen über das Betriebssystem und die laufenden Programme. Diese Informationen kann der Zabbix-Agent liefern. Der Agent arbeitet dabei so performant, dass auf dem überwachten Host keine nennenswerten Ressourcen für das Monitoring verbraucht werden.

Der Zabbix-Agent verbraucht sehr wenige Ressourcen. Doch können die vom Agent ausgelösten Prüfungen und Datensammlungen unter Umständen erhebliche Ressourcen verbrauchen. Die meisten sogenannten Build-in-Checks lesen vom Betriebssystem bereitgestellte Monitoring-Schnittstellen aus. Diese Checks erzeugen keine nennenswerte Last, weil die Daten immer vom Betriebssystem gesammelt werden, unabhängig davon, ob ein Monitoring-Agent diese auswertet.

Aufbau der Item-Keys

Sobald Sie als Item-Typ „Zabbix-Agent“ oder „Zabbix-Agent (active)“ ausgewählt haben, gelangen Sie über Select zur Liste der verfügbaren Items, welche der Agent liefern kann. Bis zur Version 2.0 wurde die Auswahl des Item-Typs im Popup mit der Item-Liste nicht übernommen. In diesem Popup müssen Sie oben rechts erneut auswählen, von welchem Typ Sie ein Item anlegen.

Sobald Sie im Popup einen Item-Key auswählen, wird dieser in das Feld „Key“ übernommen. Viele Items müssen mit hostspezifischen Parametern ergänzt werden. Diese Parameter fügen Sie innerhalb der eckigen Klammern ein.

Wenn also das Item zum Beispiel system.cpu.load[<cpu>,<mode>] heißt, dann tragen Sie im Feld Item system.cpu.load[all,avg5] ein. Das bedeutet, Sie messen die Auslastung aller CPUs mit dem Durchschnittswert der letzten fünf Minuten.

Wenn Sie die Optionen der Item-Keys auch im Namen des Items angeben möchten, können Sie im Namen die Variablen $1, $2, $3 usw. verwenden.

Überwachung der CPU-Last mit dem Zabbix-Agenten

Beispiel 1: Neues Item anlegen

Wählen Sie über das Hauptmenü Configuration|Hosts und mit dem Dropdown-Menü oben rechts eine Hostgruppe aus. Klicken Sie in der Liste der Hosts in der Zeile eines Hosts auf den Link Items. Sie sehen die Liste der konfigurierten Items für den entsprechenden Host. Klicken Sie oben rechts auf Create Item. Nun legen Sie ein neues Item an, welches die prozentuale Auslastung der CPU durch sogenannte User-Prozesse misst. Klicken Sie auf den Button Select hinter dem Eingabefeld Key und wählen Sie im Popup system.cpu.util aus. Ergänzen Sie dann die Optionen des Keys wie folgt: system.cpu.util[all,user,avg1]. Füllen Sie die restlichen Felder wie im Screenshot abgebildet aus.

Einrichten eines Items, welches die CPU-Auslastung misst

Nachdem Sie das neue Item gespeichert haben, prüfen Sie, ob Daten auf dem Zabbix-Server ankommen. Klicken Sie dazu im Hauptmenü auf Monitoring|Latest Data. Wählen Sie im Dropdown-Menü rechts oben die Hostgruppe und den Host aus. Anschließend klicken Sie auf das Pluszeichen rechts neben CPU Utilization.

Beispiel 2: Items klonen

In der Liste der Items für den ausgewählten Host sollte jetzt mindestens ein Item aufgelistet werden. Klicken Sie in der Liste der Items auf den Link CPU Usage user (avg1). Sie befinden sich wieder in der Maske zum Anlegen oder Ändern eines Items aus Beispiel eins. Klicken Sie nun unten rechts auf die Schaltfläche Clone. Damit legen Sie ein neues Item an, welches schon mit den Werten des vorherigen Items vorausgefüllt ist. Ändern Sie nun die zweite Option des Item-Keys auf idle, so dass im Feld „Key“ Folgendes steht: system.cpu.util[all,idle,avg1]. Den Namen des Items brauchen Sie nicht zu ändern. Durch die Verwendung der Variablen wird die Option „Idle“ automatisch in den Namen übernommen.
Nachdem Sie das Item gespeichert haben, klonen Sie dieses noch weitere drei Male. Verwenden Sie dann als zweite Option für system.cpu.util[all,<OPTION2>,avg1] folgende Parameter:system, nice und iowait.
Die Liste der Items sollte dann fünf Items enthalten. Wenn Sie einen Item-Key fehlerhaft angeben oder ein Item unter einem bestimmten Betriebssystem nicht existiert, wechselt das Item in den Status „Not supported“. Wenn Sie mit der Maus über das rote Icon in der Spalte „Error“ fahren, bekommen Sie einen Hinweis auf die mögliche Ursache.

Liste der Items. Fehlermeldung per Mouseover.

Über Monitoring|Latest Data prüfen Sie wieder, ob alle Daten korrekt auf dem Zabbix-Server ankommen.

Ablesen der zuletzt gemessenen Daten in Zabbix 2.4
In Zabbix 3 sehen die letzten Daten etwas anders aus, das Prinzip ist dasselbe.

Welche Daten kann der Agent liefern?

Die komplette Liste der Items, für die der Zabbix-Agent Daten liefern kann, finden Sie in der offiziellen Zabbix-Dokumentation.
Beachten Sie, dass nicht alle Items unter allen Betriebssystemen zur Verfügung stehen. Einige Items wurden erst in die aktuellste Zabbix-Version aufgenommen. Der „offiziellen“ Item-Liste können Sie die verlangte Version von Server und Agenten entnehmen.

In der nachfolgenden Liste finden Sie eine Auswahl der wichtigsten Items.

Zabbix-Agent, Systeminformationen

agent.version
Versionsnummer des Agenten im Format Character. Nützlich zur Prüfung, ob Sie die Agenten updaten müssen.

agent.ping
Prüft, ob der Agent Daten liefert. Das Item hat immer den Wert 1. Wenn der Agent keine Daten liefert, hat das Item entweder keinen Wert (NULL, nicht verwechseln mit 0) oder den Wert 1, aber mit einem veralteten Aktualisierungsdatum. Wenn Sie per Trigger prüfen möchten, ob ein Agent Daten liefert, müssen Sie die Trigger-Funktion agent.ping.nodata(sec) verwenden, zum Beispiel: {<HOST_OR_TEMPLATE>:agent.ping.nodata(3600)}=1

system.hostname
Liefert den Hostnamen des überwachten Hosts als Character zurück.

system.localtime
Liefert die Uhrzeit (Unix-Timestamp) des überwachten Hosts als Numeric (unsigned) zurück. Wichtiges Item, um sicherzustellen, dass auf allen Hosts die Uhren richtig gestellt sind.

system.uptime
Liefert die Zeit in Sekunden seit dem Start des Hosts als Numeric (unsigned). Nützlich, um zum Beispiel Warnungen zu verschicken, wenn ein System neu gestartet wurde.

system.users.num
Liefert die Anzahl der momentan angemeldeten Benutzer. Nützlich für Sicherheitsüberwachungen.

system.uname
Liefert Information über das Betriebssystem als Character zurück. Entspricht unter Linux der Ausgabe des Kommandos uname. Beispiele für die Rückgabewerte:
Windows <HOSTNAME> 6.1.7601 Windows Server 2008 Service Pack 1 AMD-64
Windows <HOSTNAME> 5.2.3790 Windows Server 2003 Service Pack 2 Intel IA-32
Linux <HOSTNAME> 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 GNU/Linux

system.sw.arch
Liefert die Architektur des Systems, zum Beispiel i686, als Character zurück.

system.sw.os[<info>]
Liefert den Namen eines Unix-Betriebssystems zurück, zum Beispiel Ubuntu 2.6.35-28.50-generic 2.6.35.11. Als Optionen können angegeben werden:

  • full: Liest /proc/version aus.
  • short: Liest /proc/version_signature aus.
  • name: Liest /etc/issue.net aus.

system.sw.packages[<package>,<manager>,<format>]
Listet unter Linux die installierten Programme auf. Rückgabe als Liste mit Komma getrennt (Text). Wenn Sie Package nicht angeben, werden alle installierten Pakete zurückgegeben. Wenn Sie für die Option Package einen regulären Ausdruck angeben, werden nur die Pakete zurückgeliefert, auf die der Ausdruck passt. Mit der Option Manager müssen Sie angeben, welchen Paketmanager das System verwendet. Möglich sind:

  • dpkg: Führt dpkg –get-selections aus.
  • pkgtool: Führt ls /var/log/packages aus.
  • rpm: Führt rpm -qa aus.
  • pacman: Führt pacman -Q aus.

Als Format können Sie „full“ oder „short“ angeben. Beispiele:

zabbix-agent -t system.sw.packages[^mysql,dpkg,full]
[dpkg] mysql-client-5.1, mysql-common, mysql-server, mysql-server-5.1, mysql-server-core-5.1
zabbix-agent -t system.sw.packages[(^nginx|^apache|^lighttpd),dpkg,short]
apache2, apache2-mpm-prefork, apache2-utils, apache2.2-bin, apache2.2-common

kernel.maxfiles, kernel.maxproc
Liefert die Anzahl der maximal möglichen offenen Dateien bzw. laufenden Prozesse. Nicht für alle Betriebssysteme verfügbar.

Netzwerk

net.if.collisions[if]
Liefert die Anzahl der Netzwerkkollisionen (Numeric (unsigned)) zurück, so wie es auch das Kommando ifconfig liefert. Sinnvoll in Halbduplex-Netzen. In einem Halbduplex-Ethernet-Netzwerk wird eine Kollision durch zwei Geräte (Netzwerkkarten) verursacht, die zur selben Zeit Daten übermitteln.
Beispiel: net.if.collisions[eth0]

net.if.in[if <,mode>]
Eingehender Netzwerkverkehr als Numeric (unsigned). Wird kein „Mode“ angegeben, werden die eingehenden Bytes des Gerätes geliefert. Mögliche Modi sind:

  • bytes - Anzahl der Bytes (Standard)
  • packets - Anzahl der Pakete
  • errors - Anzahl der Fehler
  • dropped - Anzahl der verworfenen Pakete

net.if.out[if <,mode>]
Funktioniert analog zu net.if.in für ausgehenden Datenverkehr.

net.if.total[if,<mode>]
Summe von ein- und ausgehendem Netzwerkverkehr. Optionen analog zu net.if.in und net.if.out.

Die Items net.if.in und net.if.out sollten zusammen mit der Option „Store Value Delta (speed per seconds)“ benutzt werden. Wenn Sie als Unit „Bps“ eintragen, erhalten Sie die Datendurchsatzrate des Gerätes in Bytes pro Sekunde. Wenn Sie statt Byte lieber Bit und den Durchsatz in Bit/sec messen möchten, verwenden Sie einen Multiplier von 8 und tragen Sie als Einheit „bps“ ein.

Messen des Netzwerktraffics

net.tcp.dns[<ip,>zone]
Prüft, ob der Host unter einer IP-Adresse einen Nameserver erreichen kann und ob dieser die angegebene Zone auflösen kann. Liefert 1 oder 0 als Numeric (unsigned). Wenn Sie keine IP-Adresse des Nameservers angeben, werden die im Betriebssystem eingetragenen Nameserver verwendet.
Beispiel: net.tcp.dns[,example.com]

net.tcp.listen[port]
Prüft, ob der Port auf dem lokalen System TCP-Verbindungen entgegennimmt. Liefert 1 oder 0 als Numeric (unsigned) zurück. Die Prüfung erfolgt ähnlich wie mit dem Kommando netstat -tulpen.

net.tcp.port[<ip>, port]
Prüft, ob ein Host auf einem Port TCP-Verbindungen entgegennimmt. Wenn keine IP-Adresse angegeben ist, wird 127.0.0.1 verwendet. Liefert 1 oder 0 als Numeric (unsigned).
Die Prüfung erfolgt ähnlich wie mit dem Kommando netcat -z <IP> <PORT>.
Dies ist ein reiner TCP-Portscan, der nicht feststellt, welches Protokoll auf dem Port antwortet. Verwechseln Sie dieses Item nicht mit dem Item net.tcp.service vom Typ „Simple Check“. net.tcp.port wird vom Zabbix-Agenten auf dem überwachten Host ausgeführt, wohingegen net.tcp.service vom Zabbix-Server ausgeführt wird. Mit net.tcp.port testen Sie zum Beispiel, ob ein Webserver eine benötigte Datenbank erreichen kann. Beispiel: net.tcp.port[192.0.0.5,3306].

net.tcp.service[service<,ip><,port>]
Prüft, ob ein Host für einen Service TCP-Verbindungen entgegennimmt. Liefert 0 oder 1 als Numeric (unsigned).
Folgende Services können Sie angeben: ssh, ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp.
Wenn Sie keine IP-Adresse angeben, wird 127.0.0.1 verwendet. Wenn Sie keinen Port angeben, wird der Standardport des Service verwendet.
Beispiel: net.tcp.service[ssh,192.0.2.1] prüft, ob der überwachte Host eine TCP-Verbindung zum Port 22 des Hosts 192.0.2.1 herstellen kann.
Dies ist ebenfalls ein reiner TCP-Portscan, der nicht feststellt, welches Protokoll auf dem Port antwortet. net.tcp.service[ssh,192.0.2.1] liefert auch eine 1 zurück, wenn auf Port 22 ein Pop3-Daemon anstatt SSH lauscht.

net.tcp.service.perf[service<,ip> <,port>]
Funktioniert wie net.tcp.service[service<,ip><,port>] mit dem Unterschied, dass bei einer erfolgreichen Verbindung nicht 1, sondern die Anzahl der Sekunden als Numeric (Float) zurückgegeben wird, die für das Aufbauen der Verbindung gebraucht wurden.
Bei sehr schnellen Verbindungen zeigt Ihnen Zabbix auf der Weboberfläche im Menü „Latest Data“ eine Null an. Das bedeutet, die Verbindung war so schnell, dass der Wert auf Null abgerundet wurde. Intern arbeitet Zabbix aber mit exakten Messwerten, so dass ein Trigger mit der Funktion „Wert=0“, das heißt Dienst nicht verfügbar, nicht auslöst.

Prozesse

proc.num[<name>,<user>,<state>,<cmdline>]
Liefert die Anzahl aller laufenden Prozesse zurück. Mit den Optionen „Name“ und „Cmdline“ wird geprüft, ob bestimmte Prozesse laufen. Unter Windows werden nur die Optionen „Name“ und „User“ unterstützt. Beispiele:

  • proc.num[apache2] liefert die Anzahl der laufenden Apache-Prozesse zurück.
  • proc.num[perl,,,rsnapshot daily] liefert die Anzahl der Perl-Prozesse zurück, die das Skript rsnapshot daily ausführen.
  • proc.num[perl,,,"my_script[0-9]\.pl"] Für die Filterung auf das komplette Kommando können Sie reguläre Ausdrücke verwenden.
  • proc.num[,zabbix] liefert die Anzahl alle Prozesse zurück, die vom Benutzer zabbix ausgeführt werden.
  • proc.num[,,zomb] liefert die Anzahl aller Zombie-Prozesse. Als Filter für den Status können Sie run, sleep oder zomb verwenden. Ohne Angabe des Status werden alle Status ausgewählt.

proc.mem[<name> <,user><,mode><,cmdline>]
Liefert den Speicherverbrauch eines Programms in Bytes (Numeric Float) zurück. Die Filterung des Programms erfolgt wie bei proc.num. Als Modi können „avg“, „max“, „min“ oder „sum“ (default) angegeben werden.
Beispiel: proc.mem[zabbix_server,,avg]

CPU-Auslastung

system.cpu.load[<cpu><,mode>]
Liefert den Wert Load Average als Numeric (float) zurück, wie ihn die Programme uptime oder top liefern.
Wenn keine CPU-Nummer angegeben wird, werden alle CPUs gemessen. Als Modi können „avg1“ (Standard), „avg5“ und „avg15“ angegeben werden.
Ein Computer im Leerlauf hat eine Last (Load) von 0. Jeder Prozess, der die CPU benutzt oder auf die CPU wartet, erhöht den Load-Wert um eins und zieht eins wieder ab, sobald er beendet ist. Ein Load Average von 1.73 während der letzten Minute (avg1) kann so interpretiert werden, dass die CPU zu 73% überlastet war. 0.73 Prozesse mussten auf die CPU warten und konnten nicht sofort bearbeitet werden. Das Item system.cpu.load berücksichtigt nicht die Anzahl der Prozessoren oder Kerne. Auf Mehrprozessor- oder Mehrkern-Systemen sollte die Load Average durch die Anzahl der Prozessoren oder Kerne geteilt werden.
Beispiel:
system.cpu.load[,avg15] gibt die durchschnittliche Last der letzten 15 Minuten zurück.

system.cpu.switches
Liefert die Anzahl der CPU-Kontext-Switches als Numeric (unsigned) zurück. Nur sinnvoll, wenn der Wert als „Delta (speed per second)“ gespeichert wird, das heißt Kontext-Switches pro Sekunde. Viele Kontext-Switches pro Sekunde bedeuten in der Regel eine hohe Auslastung des Systems. Nur verfügbar für Solaris und FreeBSD.

system.cpu.util[<cpu><,type><,mode>]
Liefert die prozentuale Auslastung der CPU(s) als Numeric (float), so wie es der Befehl top anzeigt. Wenn Sie keine CPU-Nummer angeben, werden alle CPUs und Kerne berücksichtigt. Als Typ können Sie angeben:

  • „idle“: Leerlaufprozess. Je geringer der Anteil an Leerlauf, desto stärker ist das System ausgelastet.
  • „user“: CPU-Benutzung durch Prozesse im „User-Space“, in der Regel Programme und Daemons.
  • „system“: System- und Kernelprozesse.
  • „nice“: Prozesse, die mit einem positiven Nice-Wert gestartet sind, die also nicht bevorzugt abgearbeitet werden.
  • „iowait“: Prozesse, die auf das IO-System warten.
  • „interrupt“
  • „softirq“:
  • „steal“: Steal time gibt den Teil der CPU-Auslastung an, den eine virtuelle CPU damit verbringt auf die reale CPU des Hypervisors zu warten, während dieser andere virtuelle Maschinen bedient.
  • „guest“
  • „guest_nice“

Beispiel:
system.cpu.util[,user,avg5] liefert den durchschnittlichen Anteil der User-Prozesse an der Gesamtauslastung des Systems während der letzten fünf Minuten.

Speicher und Swap

vm.memory.size[mode]
Liefert Informationen über die Auslastung des Hauptspeichers. Unter MS Windows wird die Größe und Nutzung des sogenannten Paging Files zurückgegeben. Als Modi stehen zur Auswahl:

  • total (Standard): genutzter Hauptspeicher in Bytes (Numeric unsigned)
  • shared: Hauptspeicher, der von verschiedenen Prozessen gleichzeitig genutzt wird (für Linux-Systeme nur mit Kernel 2.4 verfügbar)
  • used,free: genutzter oder freier Hauptspeicher in Bytes (Numeric unsigned)
  • pfree oder pused: freier bzw. genutzter Festplattenplatz in Prozent (pfree nicht verfügbar unter MS Windows)
  • buffers, cached: für Puffer oder Caches, zum Beispiel Filesystem Cache, verwendeter Hauptspeicher in Bytes (Numeric unsigned)
  • pfree: Angabe des freien Arbeitsspeichers in Prozent (Numeric float)
  • available: Gesamtgröße des installierten Hauptspeichers in Bytes
  • active, inactive: Speicher, der aktuell in bzw. nicht Benutzung ist (steht unter Linux nicht zur Verfügung)
  • exec: ausführbarer Code im Speicher (steht unter Windows und Linux nicht zur Verfügung)

system.swap.in[<device>,<type>] und system.swap.out[<device>,<type>]
Liefert Information über die Nutzung des Swap-Speichers (steht unter Windows nicht zur Verfügung).

system.swap.size[<device><,mode>]
Liefert Informationen über die Benutzung des Swap-Speichers als Numeric (float). Als Modus kann angegeben werden:

  • total: gesamter zur Verfügung stehender Swap-Speicher in Bytes
  • free: freier Swap-Speicher in Bytes bzw. freier Speicher im Pagefile
  • used: genutzter Swap-Speicher in Bytes bzw. genutzter Speicher im Pagefile
  • pused: prozentuale Nutzung des Swap-Speichers (nicht verfügbar unter Windows)
  • pfree: prozentualer freier Swap-Speicher

Beispiel:system.swap.size[,pused] zeigt an, wie viel Prozent des gesamten Swap-Speichers genutzt werden.

Dateisysteme und Festplatten

vfs.fs.size[fs,mode]
Liefert Informationen über die Auslastung eines Dateisystems. Als Dateisystem (fs) wird der absolute Pfad zum Mountpoint oder ein Laufwerksbuchstabe angegeben, zum Beispiel /home oder c:.
Als Dateisystem kann auch ein Pfad zu einem Nicht-Mountpoint (Ordner) angegeben werden. Der Rückgabewert ist dann gleich dem Wert der Festplatte, in der sich der Ordner befindet.
Als Modi stehen zur Auswahl:

  • „total“ (Standard: Gesamtgröße des Dateisystems in Bytes, Numeric (unsigned)
  • „free“ oder „used“, das heißt freier bzw. genutzter Platz des Dateisystems in Bytes, Numeric (unsigned)
  • „pfree“ oder „pused“, das heißt freier bzw. genutzter Platz des Dateisystems in Prozent, Numeric (float)

Beispiele:

  • vfs.fs.size[c:,free]
  • vfs.fs.size[/var/lib/mysql,used]

vfs.dev.read[device <,type> <,mode>] und vfs.dev.write[device <,type> <,mode>]
Liefern Informationen über lesende oder schreibende Zugriffe auf das IO-System als Numeric (unsigned).
Das Device wird ohne Präfix „/dev/“ angegeben. Es kann eine komplette Festplatte, zum Beispiel sda, oder eine Partition, zum Beispiel hda4, angegeben werden. Unter Windows wird der Laufwerksbuchstabe angegeben. Wird kein Device angegeben, werden alle Devices berücksichtigt.
Als Typen stehen „sectors“, „operations“, „bytes“, „sps“, „ops“ oder „bps“ zur Auswahl. Nicht alle Typen werden von allen Betriebssystemen unterstützt. Die Optionen „bytes“ und „bps“ stehen unter Linux nicht zur Verfügung. Wenn Sie die Anzahl der gelesenen oder geschriebenen Bytes messen wollen, messen Sie die Sektoren und geben Sie als Custom Multiplier die Sektorengröße an, welche Sie mit cat /sys/block/sda/queue/hw_sector_size ermitteln können.
Die Werte sollten als „Delta (speed per sec)“ gespeichert werden.
Beispiele:
vfs.dev.read[,operations] Gibt die gesamte Anzahl der lesenden IO-Operationen (pro Sekunde) auf allen Festplatten an.
vfs.dev.read[sda1,operations] Gibt die Anzahl der lesenden IO-Operationen (pro Sekunde) auf Festplattenpartition /dev/sda1 an.
vfs.dev.write[c:,bytes,avg5] gibt die Anzahl der geschrieben Bytes (pro Sekunde) auf Festplatte c: an.

Anlegen eines Items zur IO-Statistik über das Device /dev/sdb1
Gesammelte IO-Statistiken über das Device /dev/sdb1

vfs.fs.inode[fs,<mode>]
Liefert Informationen über die Inodes in einem Dateisystem. Als Dateisystem (fs) wird der absolute Pfad zum Mountpoint oder ein Laufwerksbuchstabe angegeben, zum Beispiel /home oder c:.
Als Dateisystem kann auch ein Pfad zu einem Nicht-Mountpoint angegeben werden. Der Rückgabewert ist dann gleich dem Wert des Mountpoints.
Als Modi stehen zur Auswahl:

  • total (Standard): Gesamtzahl der Inodes, Numeric (unsigned)
  • free oder used: freie bzw. genutzte Inodes, Numeric (unsigned)
  • pfree oder pused: Angabe in Prozent über freie bzw. genutzte Inodes, Numeric (float)

Beispiel: vfs.fs.inode[/tmp,pfree] zeigt an, wie viel Prozent freie Inodes in /tmp verfügbar sind.

Dateien

vfs.file.cksum[file]
Liefert die md5-Checksumme einer Datei zurück. Diese ist nützlich für Sicherheitsüberwachungen, wenn das Item als „Delta (simple change)“ gespeichert wird. Sobald das Delta nicht gleich Null ist, können Sie erkennen, dass sich eine Datei verändert hat. Beachten Sie aber, dass der Agent nicht mit Root-Rechten läuft und deshalb auf viele Systemdateien, zum Beispiel /etc/shadow, keinen Zugriff hat. Beachten Sie außerdem, dass eine Änderung an einer Datei nur einmal registriert wird, denn bei der nächsten Messung ist das Delta zur vorherigen Messung wieder Null.

vfs.file.regexp[file, regex]
Sucht nach einem regulären Ausdruck in einer Datei. Liefert den gefundenen Ausdruck als Text zurück.
Beispiel:vfs.file.regexp[/etc/hosts,".*"] liefert den kompletten Inhalt der Datei /etc/hosts zurück.

vfs.file.regmatch[file, regex]
Analog zu vfs.file.regexp[file, regex]. Liefert 0 oder 1 als Numeric (unsigned) zurück, wenn der Ausdruck gefunden wurde.

vfs.file.size[file]
Liefert die Größe einer Datei in Bytes als Numeric (unsigned) zurück. Wenn die Datei ein symbolischer Link ist, wird die Größe des Ziels zurückgegeben.

vfs.file.time[file,mode]
Liefert die Dateizeitinformation (Unixtimestamp) als Numeric (unsigned) zurück. Als Modi stehen zur Auswahl:

  • modification: Zeitstempel der letzten Änderung des Dateiinhaltes, Änderungen der Berechtigungen ändern den Zeitstempel modification nicht
  • access: Zeitstempel der letzten Benutzung
  • change: Zeitstempel der letzten Statusänderung, zum Beispiel Änderung des Inhaltes, der Berechtigungen oder der Inodes

Sonstiges

web.page.get[host,<path>,<port>]
Lädt eine Webseite herunter und speichert den Quelltext inklusive HTTP-Header als Text. Ein HTTP_USER_AGENT wird bei der Anfrage nicht gesetzt.

web.page.perf[host,<path>,<port>]
Lädt eine Webseite herunter und speichert in Sekunden, wie lange der Vorgang gedauert hat (Numeric float).

web.page.regexp[host,<path>,<port>,<regexp>,<length>]
Lädt eine Webseite herunter und speichert den Teil, der auf den regulären Ausdruck passt. Die Länge der gespeicherten Fundstelle kann mit der Option „Length“ verkürzt werden. Wird der reguläre Ausdruck nicht gefunden, liefert der Agent die Zeichenkette EOF zurück.
Beispiele:
web.page.regexp[www.example.com,/health.php,80,"everything ok"]
web.page.regexp[www.example.com,/site.php,80,"HTTP/1.1 [0-9]+"]

system.run[command,<mode>]
Führt auf dem überwachten Host ein Kommando aus und liefert die Rückgabe von STDOUT an den Zabbix-Server. Das Kommando wird vom Zabbix-Agenten ausgeführt. Dieser läuft auf Unix-Systemen in der Regel nicht mit Root-Rechten. Das Ausführen von Kommandos durch den Agenten ist standardmäßig deaktiviert. Zum Aktivieren setzen Sie den Wert EnableRemoteCommands=1 in der Datei zabbix_agentd.conf.
Als Modi kann wait (default) oder nowait (do not wait) angegeben werden.
Unter Unix wird das Kommando über die Standard-Shell ausgeführt. In der Regel ist dadurch ein Pfad gesetzt, so dass Kommandos nicht mit voller Pfadangabe eingegeben werden müssen. Prüfen Sie dies zum Beispiel mit zabbix-agent -t system.run[set].

Der Unterschied zwischen Zabbix-Agent und Zabbix-Agent (active)

Wenn Sie ein Item vom Typ „Zabbix agent“ einrichten, ist damit der passive Modus des Agenten gemeint. Der Zabbix-Server baut im eingestellten Intervall eine Verbindung zum Zabbix-Agenten auf und ruft die Daten ab. Dies ist eine einseitige Verbindung. Ein NAT-Routing zwischen Server und Agent stellt kein Problem dar.

Richten Sie hingegen ein Item vom Type „Zabbix agent (active)“ ein, dann meldet sich der Agent beim Server und fragt, welche Daten er wann liefern soll. Ein NAT-Routing zwischen Server und Agent kann ein Problem darstellen, wenn nicht ein entsprechendes Portforwarding eingerichtet ist. Dazu muss der sogenannte Trapper Port, in der Regel 10051 des Zabbix-Servers, vom Router an den Zabbix-Server weitergeleitet werden.

Um Items vom Typ „Zabbix agent (active)“ nutzen zu können, muss dieser Modus in der Konfigurationsdatei des Agenten eingeschaltet werden. Die von Zabbix mitgelieferte Standardkonfiguration hat den Active Mode bereits aktiviert, und der Agent ist so eingestellt, dass er sich alle zwei Minuten die Liste der zu liefernden Daten und Intervalle beim Server abholt.
Wenn Sie in der Konfiguationsdatei zabbix_agentd.conf mehr als einen Zabbix-Server eingetragen haben, dann wird nur der erste Server der Liste für aktive Checks verwendet.
Der in der Konfiguration des Agenten angegebene Hostname muss mit dem im Server hinterlegten Hostnamen übereinstimmen.

### Option: Server
# List of comma delimited IP addresses (or hostnames) of Zabbix servers.
# No spaces allowed. First entry is used for receiving list of and sending active checks.
#
# Mandatory: yes
# Default:
# Server=
Server=192.0.2.1

### Option: RefreshActiveChecks
# How often list of active checks is refreshed, in seconds.
#
# Mandatory: no
# Range: 60-3600
# Default:
# RefreshActiveChecks=120

Aktive Checks, das heißt Type=Zabbix agent (active), belasten den Zabbix-Server weniger als passive Checks. Für die aktiven Checks muss der Zabbix-Server permanent in der Datenbank nachschauen, welche Informationen er wann von welchem Host abrufen soll. Hierzu werden zwar Caches verwendet, doch reduzieren sich diese Datenbankabfragen erheblich, wenn aktive Checks eingesetzt werden. Bei aktiven Checks pflegt der Zabbix-Agent eine lokal gespeicherte Liste mit den zu liefernden Daten. Je seltener der Zabbix-Agent seine loale „To-do-Liste“ aktualisiert, desto weniger Last produziert dieser auf dem Zabbix-Server. Ändern Sie ggf. den Wert RefreshActiveChecks. Änderungen, die Sie auf dem Zabbix-Server konfigurieren, werden erst mit entsprechender Verzögerung auf den Agenten aktiv.
Solange Sie keine Performance-Engpässe mit der Datenbank feststellen, sollten Sie den passiven Modus des Zabbix-Agenten verwenden. Besonders während der Grundeinrichtung des Monitorings ist es hilfreich, wenn Sie zeitnah erkennen können, ob Items Daten liefern. Die Konfiguration des Zabbix-Agenten und die Anforderungen an das Netzwerk-Setup sind zudem wesentlich einfacher.

Ein Agent kann sowohl aktiv den Server mit Daten versorgen als auch gleichzeitig passiv auf Anfragen des Servers antworten. Ein Item, welches Daten über den Zabbix-Agenten abruft, wird wie jedes Item über einen Key ausgewählt.
Wenn Sie den Agenten nicht als Daemon, sondern per Inet-Superserver betreiben, können Sie den aktiven Modus nicht nutzen.