Zabbix Daten auswerten Trigger konfigurieren

Das Trigger-Prinzip

Trigger vergleichen den Ist-Wert eines Items mit einem Soll-Wert. Die Auswertung der Items mit Triggern führt dazu, dass der Trigger entweder auslöst, das heißt den Wert „PROBLEM“ annimmt. Oder der Trigger löst nicht aus: Er nimmt den Wert „OK“ an.

Nachdem Sie Hosts und Items konfiguriert haben, speichert der Zabbix-Server die Werte der Items in der Datenbank ab. Für einige Items mag es ausreichend sein, dass Sie diese ohne weitere Verarbeitung in der Datenbank speichern. Bei der Analyse eines Problems können Sie diese Daten dann zurate ziehen.

Bei den meisten Daten werden Sie aber eine sofortige Auswertung (Trigger) einrichten, die unmittelbar nach der Speicherung in der Datenbank erfolgt.

In der Konfiguration der Aktionen, zum Beispiel dem Versenden von E-Mails, werden dann nur noch die Triggerstatus ausgewertet.

Über die Trigger definieren Sie, welcher der Normalzustand eines Items ist. Wenn keine Fehler vorliegen, dann sollte der Trigger nicht auslösen, also den Wert „OK“ haben.

Liegt ein Störfall vor, dann weicht der Wert eines Items vom Normalzustand ab, und der Trigger löst aus, er nimmt also den Wert „true“ an.

Welche Aktionen ein Trigger auslöst, bestimmt nicht der Trigger. Sobald ein Trigger seinen Status verändert, werden alle konfigurierten Aktionen darüber informiert. Die Konfiguration der Aktion entscheidet dann, ob diese „zuständig“ ist und zum Beispiel eine Mail versendet wird.

Beispiel Prozessorauslastung überwachen

Im Beispiel in Kapitel Daten mit dem Zabbix-Agenten sammeln haben Sie ein Item angelegt, welches die sogenannte Idle-Time des Prozessors misst. Sie werden nun einen Trigger anlegen, der Alarm schlägt, wenn der Prozessor über einen Zeitraum von fünf Minuten stark ausgelastet ist.

Wechseln Sie über das Hauptmenü Configuration|Hosts zur Liste der Hosts. Wählen Sie über das Dropdown-Menü oben rechts die passende Gruppe aus, in der sich der Host aus dem vorangegangenen Beispiel befindet. Klicken Sie dann auf den Link Triggers in der Zeile des entsprechenden Hosts. Über den Knopf Create Trigger oben rechts legen Sie einen neuen Trigger an. Als Namen geben Sie „Few Idle“ ein.

Mit Klick auf den Button Add hinter dem Eingabefeld „Expression“ öffnet sich ein Pop-up-Fenster zur Eingabe der Trigger-Bedingung (Condition). Die Schaltfläche Select hinter dem Eingabefeld „Item“ öffnet noch ein Fenster. In diesem wählen Sie dann das Item „CPU idle time (avg1)“ aus. Über das Dropdown-Menü „Function“ wählen Sie Average value for period of T times < N aus. Im Eingabefeld „Last of (T)“ geben Sie zum Beispiel 300 Sekunden ein. Im Feld „N“ geben Sie zum Beispiel 50 ein. Speichern Sie Ihre Eingabe mit dem Knopf Insert ab.

Nachdem alle Pop-up-Fenster geschlossen sind, wählen Sie als Severity „Warning“ aus und speichern den Trigger mit dem Button Save.

Sie haben jetzt einen Trigger angelegt, der auslöst, sobald die durchschnittliche Leerlaufzeit während der letzten 5 Minuten den Wert 50 unterschreitet. Es wird also nicht nur der letzte Messwert, sondern es werden alle Messwerte des ausgewählten Zeitraums berücksichtigt. Damit vermeiden Sie Fehlalarme durch nicht kurzzeitige Lastspitzen.

Anlegen eines Triggers, der die Leerlaufzeit der CPU auswertet

Erzeugen Sie nun Last auf Ihrem überwachten Host, zum Beispiel mit dem Kommando cpuburn. Klicken Sie dann auf Monitoring|Triggers und wählen Sie den entsprechenden Host über die Dropdown-Menü oben rechts aus. Nach einiger Zeit sollte in der Liste der Trigger „Few Idle“ mit dem Status „Problem“ auftauchen.

Status der Trigger für einen Host

Einrichten eines Triggers

Trigger können für einzelne Hosts oder für Templates eingerichtet werden. Wenn Sie für ein Template ein Item eingerichtet haben, können Sie auch für dieses Template Trigger konfigurieren. Sobald ein Template über einen Trigger verfügt, benutzen alle Hosts, die das Template verwenden, diesen Trigger auch.

Wie bereits erwähnt, sollten Sie möglichst viele Items und Trigger über Templates einrichten. Das erleichtert die Verwaltung eines großen Setups sehr.

Zum Einrichten eines Triggers wählen Sie im Menü Configuration|Hosts zuerst eine Gruppe aus und klicken dann in der Zeile eines Hosts oder Templates auf „Trigger“. Sie sehen die Liste aller Trigger für diesen Host oder Templates. Oben rechts finden Sie den Knopf Create Trigger.

Aufbau eines Triggers

Name
Geben Sie dem Trigger einen aussagekräftigen Namen. Der Name des Triggers wird bei allen Aktionen, zum Beispiel beim Versenden von E-Mails, verwendet. Der Name des Triggers sollte Ihnen kurz und präzise Auskunft darüber geben, was passiert ist.

Beispiele: „ICPM Ping failed“, „HTTP Port Check failed“, „Load Avg5 higher 10“

Das Hinzufügen von Hostnamen in den Triggernamen ist nicht notwendig. Wenn Sie einen Trigger für ein Template einrichten, wird der Trigger von vielen Hosts verwendet, und ein in den Triggernamen fest eingetragener Hostname würde dann eine falsche Informationen weitergeben. Das Hinzufügen des Hostnamens, für den ein Trigger auslöst, ist Aufgabe der Aktionen. Dort steht der Hostname des Triggers als Variable zur Verfügung.

Expression
Über die Expression wird definiert, welches Item mit welchem Wert verglichen werden soll. Über den Knopf Insert öffnet sich ein weiteres Menü, über das Sie als Erstes das Item auswählen, welches der Trigger auswerten soll.

Achten Sie darauf, dass Sie den richtigen Host auswählen, und klicken Sie dann auf ein Item.

Sie legen zwar den Trigger für einen bestimmten Host oder ein bestimmtes Template an, könnten aber trotzdem Items anderer Hosts für den Trigger verwenden. Deshalb müssen Sie bei der Auswahl des Items noch einmal einen Host angeben. In der Regel ist das derselbe Host oder dasselbe Template, für die Sie auch den Trigger anlegen.

Sobald Sie ein Item ausgewählt haben, wird dieses zusammen mit dem Host- oder Templatenamen in das Feld „Item“ übernommen.

Wählen Sie dann eine Funktion aus. Zum Beispiel „Last value = N“ und „N=0“. Das bedeutet, der Trigger löst aus, wenn der letzte gemessene Wert des Items gleich Null ist.

Das Anlegen der Expression beenden Sie mit dem Knopf „Insert“. Im Feld „Expression“ ist nun ein Ausdruck eingetragen, welchen Sie auch noch manuell ändern können (Beispiel:{Mailserver:pop.last(0)}=0).

Nutzen Sie die Kommentare und die URL, um den Notdienst mit den wichtigsten Informationen zur Fehlerbeseitigung zu versorgen.

Operatoren
In der Zabbix-Version 2.2 können mehrere Expressions mit den logischen Operatoren „&“ (Logisches Und) oder „|“(Logisches Oder) verbunden werden. Ab Version 2.4 müssen Sie and und or als logische Operatoren angeben. Beispiel für logisch verknüpfte Expressions:

{Template OS Linux:system.cpu.util[,idle].avg(120)}<40 and {Template OS Linux:system.cpu.util[,user].avg(120)}>70 # Zabbix 2.4
{Template OS Linux:system.cpu.util[,idle].avg(120)}<40 & {Template OS Linux:system.cpu.util[,user].avg(120)}>70   # Zabbix 2.2

In Zabbix 2.4 hat sich außerdem der Ungleich-Operator von # zu <> geändert. Beispiele:

{Mailserver:pop.last(0)}#0   =>Zabbix 2.2
{Mailserver:pop.last(0)}<>0  =>Zabbix 2.4

Sie können außerdem auf die vier Operatoren der Grundrechenarten zurückgreifen: +(Addition), -(Subtraktion), *(Multiplikation), /(Division). Wenn Sie beispielsweise einen Trigger einrichten, der auslösen soll, sobald eine Festplatte über weniger als zwei Gigabyte freien Speicher verfügt, können Sie den Trigger wie folgt definieren. Die Verwendung eines User-Makros ist ebenfalls möglich, wenn Sie die Schwellwerte individuell festlegen möchten:

{<HOST>:vfs.fs.size[/,free].last(0)}<2*1024*1024*1024
{<HOST>:vfs.fs.size[/,free].last(0)}<{$MIN_FREE_HDD}*1024*1024*1024

{Hinweis|Achten Sie bei der Verwendung der Operatoren and, or und not auf die Kleinschreibung (case-sensitive lowercase). Die Operatoren müssen außerdem zwischen zwei Leerzeichen stehen.}

Schweregrad der Störung:
Über diese Auswahl geben Sie an, wie schwer das Problem ist. Die „Severity“ der Trigger wird von den Aktionen ausgewertet, und Sie können unterschiedliche Aktionen je nach Schweregrad des Problems ausführen. Die in der Liste aufgeführten Schweregrade können nicht geändert oder erweitert werden.

Hinweise für den Notdienst:
Im Textfeld Comments können, besser gesagt sollten Sie Informationen aller Art zu einem Trigger hinterlegen. Zum Beispiel könnte man über den Kommentar bereits erste Informationen hinterlegen, wie man beim Beheben des Problems vorgehen soll.

Die hinterlegten Kommentare können über das Makro {TRIGGER.COMMENT} auch in die Benachrichtigungen eingefügt werden.

Wenn Sie im Feld URL eine URL eingeben, dann werden die Trigger im Menü „Monitoring/Trigger“ als Links dargestellt. Per Klick auf den Trigger gelangt man dann zur hinterlegten URL. Die URL kann ebenfalls in Nachrichten über das Makro {TRIGGER.URL} eingefügt werden. Die URL ist nützlich, um Links zu Notfallhandbüchern, Wikis o.Ä. zu hinterlegen.

Einmal oder mehrfach auslösen:
Über den Schalter Event generation legen Sie fest, wie oft eine nachfolgende Aktion, die auf diesem Trigger basiert, ausgeführt werden soll.

„Normal“ bedeutet, dass die Aktion nur einmal ausgeführt wird, sobald der Trigger seinen Status ändert. Wenn ein Item seinen Wert nicht ändert, ändert sich auch nicht der Status des Triggers. Nachfolgende Events werden also nicht mehrfach ausgeführt. Wenn ein Host per Ping alle 30 Sekunden geprüft wird und dann für 4 Stunden nicht erreichbar ist, werden alle Events nur einmal ausgeführt. Für eine E-Mail-Benachrichtigung hieße das, dass Sie nur eine E-Mail erhalten, sobald ein Problem auftritt.

„Normal + multiple Problem events“ bedeutet, dass für jedes Intervall, in dem das zugrunde liegende Item abgerufen wird, die Aktion ausgeführt wird, vorausgesetzt, der Trigger hat den Status TRUE. Für eine E-Mail-Benachrichtigung hieße das, dass Sie permanent im Intervall des Items E-Mails erhalten, solange ein Problem besteht.

Wenn Sie eine Erinnerungsnachricht erhalten möchten, weil Probleme über eine längere Zeit fortbestehen, nutzen Sie nicht die Option „multiple Problem events“. Wenn Sie „multiple Problem events“ für ein Item mit Update-Intervall 30 Sekunden nutzen würden, bekämen Sie alle 30 Sekunden eine Mail. Das wollen Sie wahrscheinlich nicht. Nutzen Sie stattdessen den Eskalationsmodus in den Aktionen. Dort können Sie den Zeitpunkt einer Erinnerungsnachricht unabhängig vom Messintervall eines Items festlegen.

Triggerabhängigkeiten definieren:
Über Abhängigkeiten (New dependency/Trigger depends on) können Sie mehrere Trigger miteinander verknüpfen. Über diese Verknüpfungen können Sie Abhängigkeiten in der Netzwerkstruktur auch in Zabbix abbilden.

Wenn der Zabbix-Server zur Überwachung mehrerer Hosts einen bestimmten Router verwendet, sollten Sie die Verfügbarkeit des Routers überwachen. Fällt der Router aus, wird Zabbix alle Hosts „hinter“ diesem Router als nicht verfügbar markieren. Diese Information ist aber streng genommen falsch. Über eine „Dependency“ sollten Sie konfigurieren, dass, wenn der Router nicht erreichbar ist, alle Trigger, die auf diesen Router angewiesen sind, nicht auslösen.

Beispiel: Für einen Host gibt es zwei Trigger: „No Ping. Host Down“ und „SSH not listening“. Wenn Sie nun für den Trigger „SSH not listening“ im Feld „Trigger depends on“ den Trigger „No Ping. Host Down“ hinzufügen, wird der Trigger „SSH not listening“ nur dann auslösen, wenn der Trigger „No Ping. Host Down“ den Wert „kein Problem“ hat. Das bedeutet, ist der Host nicht per Ping erreichbar, wird der Test des SSH-Servers ignoriert.

Dieser Trigger wird ignoriert, wenn der Host komplett „down“ ist.
Alle Trigger, die auf Items vom Type „Zabbix-Agent“ oder „Zabbix-Agent active“ basieren, lösen nicht aus, sobald der Zabbix-Agent keine Daten mehr liefert. Dies kann Fluch und Segen zugleich sein. Sie brauchen keine Abhängigkeit zur Verfügbarkeit des Agenten definieren. Andererseits ist das Ausbleiben von aktuellen Daten in vielen Fällen auch ein kritisches Ereignis. Überwachen Sie deshalb immer, ob der Zabbix-Agent generell Daten liefert. Das Kapitel Zabbix_unsupported_Items beschäftigt sich ausführlich mit dem Thema.

Beispiel Kurvenausreißer erkennen

Im nachfolgenden Screenshot sehen Sie die Anzahl der gestarteten Apache-Prozesse eines Webservers. Im Normalbetrieb variieren diese zwischen 6 und 100. Um 20.30 Uhr gab es einen schlagartigen Anstieg der Prozesse, und kurz vor 23 Uhr konnte der Webserver seine Startseite nicht mehr ausliefern.

Anzahl der Apache-Prozesse und die Auswirkung auf die Verfügbarkeit einer Webseite

Wie kann man nun solche Abnormalitäten mit Zabbix erkennen und sich alarmieren lassen?

  • Sie können die Verfügbarkeit einer Webseite messen und Alarm auslösen, wenn diese offline ist. Dann können Sie aber nur noch reaktiv handeln.
  • Sie können einen Alarm auslösen, sobald die Anzahl der Apache-Prozesse über 120 liegt. Doch jeder Webserver kann anders ausgelastet sein. 120 Prozesse kann auf einem anderen System Normalzustand sein.
  • Sie können einen Trigger definieren, der den schlagartigen Anstieg der Prozesse erkennt. Das nachfolgende Beispiel erklärt, wie das geht, mit einer Art „Trockenübung“.

Vorbereitungen:

  • Legen Sie zum Beispiel für den Zabbix-Server ein Item vom Type „Zabbix-Trapper“ mit dem Namen „Random Number“ und dem Key random.number an.
  • Schicken Sie per Zabbix-Sender alle 10 Sekunden eine Zufallszahl zwischen 1 und 100 an dieses Item.
while true
   do zabbix_sender -z 127.0.0.1 -s srv01.example.com \
   -k random.number -o $(shuf -i 1-100 -n 1)
   sleep 10
done
  • Schauen Sie sich den Graphen des Items an. Der Durchschnittswert wird sich bei ca. 50 einpendeln.

Trigger einrichten:
Legen Sie nun einen Trigger mit folgendem Ausdruck an:

{srv01.example.com:random.number.avg(#10)}>
({srv01.example.com:random.number.avg(#50)}+
{srv01.example.com:random.number.avg(#50)}/2)

Die Eingabe des Triggers erfolgt ohne Zeilenumbrüche!

Trigger, der bei schlagartigem Anstieg auslöst

Testen:
Stoppen Sie die eben gestartete Endlosschleife mit Ctrl-C und senden Sie nun konstant hohe Messwerte zum Beispiel 110 an das Item:

while true
   do zabbix_sender -z 127.0.0.1 -s srv01.example.com \
   -k random.number -o 110
   sleep 10
done

Der Trigger sollten nach einigen Durchläufen der Schleife auslösen.

Trigger reagiert auf schlagartigen Anstieg eines Messwertes.

Triggerfunktionen im Detail

Die Liste aller Triggerfunktionen finden Sie in der offiziellen Dokumentation. Nachfolgend finden Sie einen Ausschnitt der wichtigsten Funktionen mit einigen Beispielen.

Triggerfunktionen werden im Webfrontend von Zabbix auf zwei Weisen bezeichnet.

  1. Mit einem aussagekräftigen Text. Diesen finden Sie in der Auswahlliste, wenn Sie beim Anlegen des Triggers die Schaltfläche „Add“ klicken. Sie werden mit einem Wizard durch den Aufbau des Triggers geführt (siehe Pfeil Nr. 2 im Screenshot).
  2. Sobald Sie die Schaltfläche „Insert“ klicken, schließt sich der Wizard und der Triggerausdruck (Expression) wird in einer Kurzform eingefügt, die wie Programmcode aussieht (siehe Pfeil Nr. 3). Diese Kurzform können Sie auch ändern. Sie brauchen nicht immer den Wizard benutzen.

In der nachfolgenden Liste mit Triggerbeispielen finden Sie beide Bezeichnungen für Triggerfunktionen. Der aussagekräftige Text ist fett gedruckt dargestellt und der kurze Ausdruck im Programmierstil in Monospace-Schriftart.

Zwei Bezeichnungen für Trigger

Differenzen

Absolute difference between last and previous value > N
Vergleicht den aktuellen Wert eines Items mit dem Wert der vorangegangenen Messung.

Mit diesen Funktionen können Sie den schlagartigen Anstieg von Messwerten überwachen. Wenn zum Beispiel innerhalb des Messintervalls des Items mehr als 5% des Festplattenplatzes verbraucht werden, ist das oft ein Hinweis auf ein anormales Verhalten.
Beispiel: {Mailserver:vfs.fs.size[/,pfree].abschange(0)}>5

Difference between MAX and MIN value of T times > N
Berechnet und vergleicht den Unterschied zwischen Minimal- und Maximalwert eines Items innerhalb einer Zeitspanne.

Mit dieser Funktion können Sie starke Schwankungen von Items überwachen, zum Beispiel die Anzahl von Abfragen einer Datenbank pro Minute. Bei langsam steigender Last weichen der Maximal- und der Minimalwert nur leicht voneinander ab. Wenn in einem kurzen Zeitraum der Maximal- und der Minimalwert aber stark auseinanderliegen, kann das ein Hinweis auf eine Störung sein. Der nachfolgende Trigger löst aus, wenn der Unterschied zwischen dem größten und kleinsten Messwert der letzten 300 Sekunden größer als 600 ist.
Beispiel: {Databaseserver:mysql.questions.delta(300)}>600

Durchschnitt

Average value for period of T times > N
Berechnet und vergleicht den Mittelwert eines Items innerhalb einer Zeitspanne.

Mit diesen Funktionen können Sie Fehlertoleranzen bei der Überwachung stark schwankender Werte einrichten. Zum Beispiel können die Werte für den Netzwerktraffic stark schwanken. Wenn aber über einen längeren Zeitraum ein erhöhter Netzwerktraffic gemessen wird, kann das ein Hinweis auf eine Störung sein. Der nachfolgende Trigger löst aus, wenn der Durchschnitt der Messungen der letzten 600 Sekunden größer als 250 ist.
Beispiel: {Mailserver:net.if.out[eth0].avg(600)}>250


Erfolgreich abgerufene Daten

Number of successfully retrieved values V for period of time T > N
Wertet die historischen Daten eines Items aus. Es wird die Anzahl von Messungen zurückgegeben, die innerhalb einer Zeitspanne einen bestimmten Wert hatten. Beispiel:
{Mailserver:icmpping.count(3600,0)}>10

count(3600,0) liefert die Anzahl der Messungen zurück, die Null ergeben haben. Der Trigger löst also aus, wenn der Host innerhalb der letzten Stunde mindestens 10-mal nicht auf Pings geantwortet hat. Diese Funktion kann Optionen wie zum Beispiel gt, lt verwenden. Siehe auch offizielle Dokumentation.

Gleich-ungleich-Prüfung

N= X, where X is 1 - if last and previous values differs, 0 - otherwise
N NOT X, where X is 1 - if last and previous values differs, 0 - otherwise
Last value > N
Previous value > N
Gleich-ungleich-Prüfungen können nur auf Items mit Zahlwerten (Integer, Float, Decimal) angewendet werden. Beispiel:
{Zabbix server:proc.num[mysqld].last(0)}=0
Der Trigger löst aus, wenn die Anzahl der MySQL-Prozesse gleich Null ist.

String-Vergleiche: Worte finden

Find string T last value. N = X, where X is 1 - if found, 0 - otherwise
Find string T last value. N NOT X, where X is 1 - if found, 0 - otherwise
Prüft, ob ein Wort in einem Item-Wert enthalten ist.

Beispiel 1

Sie haben zum Beispiel ein Item backup.status, welches Daten vom Typ Text enthält. Nun wollen Sie einen Trigger einrichten, der einen Alarm auslöst, sobald der Item-Value einen anderen Wert als „OK“ hat.
Dies erreichen Sie mit folgendem Trigger:

{backup.status.str(OK)}=0

Wenn der Item-Value den String „OK“ enthält, liefert die Funktion str(OK) 1 zurück. Dieser Rückgabewert wird mit 0 verglichen, was fehlschlägt. Folglich nimmt der Trigger den Wert OK (= kein Problem) an, weil der Vergleich fehlgeschlagen ist. Das bedeutet, es wird kein Alarm ausgelöst.
Wird der String „OK“ nicht gefunden, liefert die Funktion str(OK) 0 zurück, der Vergleich mit 0 ist erfolgreich, folglich nimmt der Trigger den Wert PROBLEM an, das heißt, es wird ein Alarm ausgelöst.

Beachten Sie, dass im genannten Beispiel gesucht wird, ob der Item-Value den String enthält, nicht ob der String gleich dem gesuchten String ist. Nähme das Item den Wert „LOKOMOTIVE“ an, würde der Trigger auch den Wert FALSE annehmen, weil OK in LOKOMOTIVE enthalten ist.

Wenn Sie nach einer exakten Übereinstimmung suchen wollen, dann verwenden Sie folgenden regulären Ausdruck mit der Triggerfunktion regexp():

{backup.status.regexp(^OK$)}=0

Beispiel 2

Sie haben zwei Items: LSI Megaraid:lsi_raid[firmware] gibt die Firmwareversion eines LSI Raidcontrollers als Buchstabenkette aus.
LSI Megaraid:lsi_raid[product_name] gibt das genaue Modell des Controllers an.

{LSI Megaraid:lsi_raid[firmware].str(6.3.0-0001)}=0&{LSI Megaraid:lsi_raid[product_name].str(PERC 6)}=1

Dieser Trigger würde auslösen, wenn die Firmwareversion nicht gleich 6.3.0-0001 ist, aber nur dann, wenn die Modellbezeichnung gleich PERC 6 ist.

Summen

Sum of values for period of time T > N
Bildet die Summe von mehreren Messwerten eines Items. Im nachfolgenden Beispiel löst der Trigger erst dann aus, wenn ein Host zwanzig Mal nicht auf Pings geantwortet hat.
{Zabbix server:icmpping.sum(#20)}=0
Fehlertoleranter Trigger, der mehrere Messwerte berücksichtigt

Zeitstempel

In vielen Situationen ist es wichtig, das Alter eines Zeitstempels (Unix-Timestamp) auszuwerten.

Mit der Funktion fuzzytime() können Sie die Abweichung eines Items von der aktuellen Uhrzeit berechnen. fuzzytime(sec) liefert 1 zurück, wenn der Itemwert nicht mehr als die angegebene Anzahl von Sekunden von der Uhrzeit des Zabbix-Servers abweicht. Da Sie in der Regel keine Messwerte aus der Zukunft erhalten, liefert fuzzytime(sec) eine Null zurück, sobald ein Messwert älter als x Sekunden ist.

Beispiel 1

{Zabbix server:system.localtime.fuzzytime(60)}=0

Der Trigger löst keinen Alarm aus, solange der Itemwert nicht mehr als 60 Sekunden von der Uhrzeit des Zabbix-Servers abweicht.

Per Trigger wird geprüft, ob die Uhr auf einem Host richtig gestellt ist.

Beispiel 2

{My_Template:rsnapshot[last_successfully_backup].fuzzytime(100800)}=0

Das Item rsnapshot[last_successfully_backup] liefert die Uhrzeit des letzten erfolgreichen Backups. Der Trigger löst einen Alarm aus, wenn das letzte Backup älter als 24 Stunden ist.
Beachten Sie, dass die Funktion fuzzytime() wie fast alle Triggerfunktionen beim Eintreffen neuer Daten ausgeführt wird.

Beispiel 3

Ein Item enthält das letzte erfolgreiche Backup als Unix-Timestamp. Im Falle eines fehlgeschlagenen Backups liefert der Zabbix-Agent oder Zabbix-Sender aber gar keine Daten. In diesem Fall würde ein Trigger mit der Funktion fuzzytime() kein Problem melden. Kombinieren Sie in solchen Fällen die Funktionen fuzzytime() und nodata().

Kombination von Fuzzytime und Nodata