Zabbix

Zabbix-Trigger-Alarme über einen Webhook-Medientyp an Uptimeify Incident Management senden, mit dem fertigen Medientyp, den Uptimeify für dich generiert.

Uptimeify bildet mit dem Zabbix-Preset die Payload eines Zabbix-Webhook-Medientyps direkt ab: Trigger-Name, Schweregrad, Status und Host sind bereits vorab gemappt. Uptimeify liefert dir außerdem einen fertigen Medientyp zum Import in Zabbix, sodass du ihn weder von Hand anlegen noch das JavaScript selbst schreiben musst.

1. Alert Source in Uptimeify anlegen

Gehe zu Incident Management → Alert Sources → Neu, wähle das Zabbix-Preset, vergib einen Namen und lege die Source an. Auf dem Erfolgsbildschirm:

Kopiere die Ingest-URL (https://deine-domain/api/im/ingest/<token>). Sie wird nur einmal angezeigt.
Lade über die Aktion Medientyp herunterladen die Datei uptimeify-zabbix-media-type.yaml herunter.

2. Medientyp in Zabbix importieren

Gehe in Zabbix zu Alerts → Media types (Zabbix 7.x; Administration → Media types bei 6.x und älter) und klicke auf Import.
Wähle die heruntergeladene uptimeify-zabbix-media-type.yaml und bestätige. Es erscheint ein Medientyp namens Uptimeify.
Hinterlege die Ingest-URL. Entweder definierst du unter Administration → Macros das globale Makro {$UPTIMEIFY.INGEST.URL} mit der URL aus Schritt 1, oder du öffnest den Medientyp und trägst die URL direkt in dessen Parameter ingest_url ein.
Aktiviere den Medientyp.

Die Ingest-URL muss ein Medientyp-Parameter sein. Zabbix löst Makros ausschließlich in Parameter-Werten auf, niemals im Script-Body, ein {$UPTIMEIFY.INGEST.URL} im JavaScript würde wörtlich als Ziel-Zeichenkette verwendet, und es käme nie ein Alarm an.

Was der Medientyp sendet

Der importierte Medientyp deklariert je einen Parameter pro Feld, das im Preset gemappt ist. Die Payload passt damit ohne weitere Anpassung auf die Selektoren des Presets:

Parameter	Zabbix-Makro	Wofür
`ingest_url`	`{$UPTIMEIFY.INGEST.URL}`	Ziel des POST
`event_id`	`{EVENT.ID}`	Dedup-Key, bleibt in der Entwarnung die ID des Problem-Events und führt beide zu einem Vorfall zusammen
`event_severity`	`{EVENT.SEVERITY}`	Schweregrad (siehe Tabelle unten)
`trigger_name`	`{EVENT.NAME}`	Titel
`trigger_status`	`{EVENT.STATUS}`	`RESOLVED` löst den Alarm auf, alles andere hält ihn offen
`host_name`	`{HOST.NAME}`	Host
`event_source`, `event_value`, `date`, `time`	jeweiliges Makro	Kontext

Das Skript wertet HTTP 200/202 als Erfolg und wirft bei allem anderen einen Fehler, eine fehlgeschlagene Zustellung erscheint damit in Zabbix als fehlgeschlagener Versuch, statt still zu verschwinden. Ein 404 bedeutet dort, dass der Token in deiner Ingest-URL zu keiner Alarmquelle gehört.

Den Medientyp testen

Der Test-Button eines Medientyps reicht in Zabbix alle Parameter wörtlich durch, Makros werden dabei nicht aufgelöst. Testest du direkt nach dem Import, kommt ingest_url als Zeichenkette {$UPTIMEIFY.INGEST.URL} an und der Versuch scheitert mit cannot get URL: URL rejected: Bad hostname. Das ist erwartetes Verhalten, keine Fehlkonfiguration.

Für einen echten Test ersetzt du im Test-Dialog den Wert von ingest_url durch deine tatsächliche Ingest-URL. Die übrigen Parameter kannst du so lassen, das Preset braucht nur trigger_name und trigger_status, um einen brauchbaren Alarm zu erzeugen, und im Dialog kannst du auch dafür echte Werte eintragen.

3. Mit einer Trigger-Action verbinden

Füge den neuen Medientyp einem Zabbix-Benutzer unter Users → Users → (Benutzer) → Media hinzu. Zabbix verlangt auch für einen Webhook einen "Send to"-Adresswert. Ein beliebiger, nicht leerer Wert funktioniert, das Skript ignoriert ihn.
Lege unter Data collection → Actions → Trigger actions eine Trigger-Action an (oder bearbeite eine bestehende) mit einer Operation, die eine Nachricht an diesen Benutzer über deinen neuen Medientyp sendet.
Trage denselben Medientyp zusätzlich unter „Recovery operations" derselben Action ein, nicht nur unter „Operations". Das ist der Schritt, der Vorfälle schließt: eine Action ohne Recovery-Operation sendet das Problem und nie die Entwarnung, der Vorfall in Uptimeify bleibt dann ausgelöst, bis ihn jemand von Hand auflöst. Unter Reports → Action log siehst du, ob Entwarnungen tatsächlich rausgegangen sind.
Löse ein Testproblem aus (oder warte auf das nächste echte) und prüfe, ob es unter Incident Management → Alert Sources → deine Zabbix-Source erscheint, und ob es sich wieder schließt, sobald der Trigger sich erholt.

Standard-Feld-Mapping

Zabbix-Webhook-Parameter	Normalisiertes Feld
`trigger_name`	Titel
`event_severity`	Schweregrad (über die Zuordnung unten)
`trigger_status`	Status: `RESOLVED` löst den Alarm auf, alles andere hält ihn offen
`host_name`	Host
`event_id`	Dedup-Key: gruppiert das PROBLEM- und das RESOLVED-Event desselben Triggers zu einem Alarm

Schweregrad-Zuordnung

Zabbix `event_severity`	Uptimeify-Schweregrad
`Disaster`	`sev1`
`High`	`sev2`
`Average`	`sev3`
`Warning`	`sev4`
`Information`	`sev4`
`Not classified`	`sev4`

Beispiel-Payload

So sieht die Payload aus, die das Zabbix-Preset von Uptimeify erwartet, dieselbe Form, die der Medientyp erzeugt:

{
  "event_id": "6633487",
  "event_source": "0",
  "event_value": "1",
  "event_severity": "Disaster",
  "trigger_name": "Zabbix agent is not available on Zabbix server",
  "trigger_status": "PROBLEM",
  "host_name": "Zabbix server",
  "date": "2026.07.17",
  "time": "12:00:00"
}

Du kannst genau diese Payload über den Tab Payload Mapping im Dashboard gegen das Mapping deiner Source senden, um den Aufbau zu prüfen, bevor du eine echte Trigger-Action verbindest.

Zabbix

Auf dieser Seite