Uptimeify Docs

Benutzerdefinierter Webhook

Alarme aus jedem Tool, das JSON per POST senden kann, an Uptimeify Incident Management schicken, mit eigenem Feld-Mapping im Dashboard.

Das Preset Benutzerdefinierter Webhook ist der Ausgangspunkt für jedes Monitoring- oder Alerting-Tool, für das es kein eigenes Preset gibt: eine Firewall-Appliance, ein internes Skript, ein Nischen-SaaS-Produkt, alles, was eine HTTP-POST-Anfrage mit JSON-Body senden kann. Anders als die übrigen Presets kommt es nur mit einem minimalen Standard-Mapping. Den Rest legst du selbst fest, sobald du die tatsächliche Payload-Form deines Tools siehst.

1. Alert Source in Uptimeify anlegen

Gehe zu Incident Management → Alert Sources → Neu, wähle das Preset Benutzerdefinierter Webhook, vergib einen Namen und lege die Source an. Kopiere auf dem Erfolgsbildschirm die Ingest-URL (https://deine-domain/api/im/ingest/<token>). Sie wird nur einmal angezeigt und danach nie wieder im Klartext eingeblendet. Solltest du sie verlieren, rotiere den Token im Tab Einstellungen der Source.

2. Dein Tool auf die Ingest-URL zeigen lassen

Konfiguriere das Webhook-/Benachrichtigungsziel deines Tools so, dass es bei jedem ausgelösten oder aufgelösten Alarm eine HTTP-POST-Anfrage mit JSON-Body an die Ingest-URL sendet. Es gibt kein festes Request-Schema auf der Empfängerseite. Sende, was dein Tool liefert.

curl -X POST "https://deine-domain/api/im/ingest/<token>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Disk usage above 90% on db-primary",
    "status": "open"
  }'

3. Feld-Mapping an deine Payload anpassen

Das Standard-Mapping extrahiert nur einen Titel und einen Status: sinnvolle Vorgaben für eine generische Payload, aber fast sicher nicht alles, was du möchtest:

  1. Sende einmal eine echte (oder repräsentative Test-)Payload aus deinem Tool, damit du die genauen Feldnamen siehst. Die Ansicht Live-Aktivität auf der Detailseite der Alert Source zeigt die zuletzt empfangenen Rohdaten.
  2. Öffne den Tab Payload Mapping der Source und bearbeite die Selektoren: Füge severity-, host- und dedupKey-Selektoren hinzu, die auf die tatsächlichen Feldnamen deiner Payload zeigen (Dot-/Bracket-Pfade wie data.host.name oder alerts[0].id werden unterstützt, ebenso a || b-Fallback-Ketten für Felder, die nicht immer vorhanden sind). Füge bei Bedarf ein severityMap hinzu, falls dein Tool ein eigenes Schweregrad-Vokabular sendet, damit es auf Uptimeifys Skala sev1 bis sev4 abgebildet wird.
  3. Speichern, und prüfe anschließend über das Testpanel im Tab Payload Mapping, ob eine Beispiel-Payload durch dein angepasstes Mapping die erwarteten Werte für Titel/Schweregrad/Status/Host liefert, bevor du dich bei echten Alarmen darauf verlässt.

Payloads ohne Statusfeld (Regex)

Manche Tools schicken nur Freitext: Beszel, der generische Webhook von Uptime Kuma, Healthchecks.io, Gatus. Es gibt kein Statusfeld und keine stabile Alarm-ID, und Alarm- und Entwarnungstitel unterscheiden sich. Jeder Selektor kann mit feld =~ /muster/ einen Wert aus Text schneiden, in derselben Schreibweise wie die E-Mail-Quelle. Der Wert ist die erste Klammergruppe, ohne Klammergruppe der ganze Treffer. Kein Treffer gilt als „nicht vorhanden“, dann greift der nächste Kandidat einer a || b-Kette. Erlaubt sind die Flags i, m, s und u; durchsucht werden die ersten 4.096 Zeichen eines Felds, und ein Muster, das eine selbst wiederholte Gruppe wiederholt ((a+)+), trifft nie.

Beispiel für Beszel (generischer Webhook, template=json), das {"title": "backend1 CPU above threshold", "message": "..."} schickt und bei der Entwarnung "backend1 CPU below threshold":

SelektorWert
titletitle
statustitle =~ /(below threshold|is up)/ mit resolveValues: below threshold, is up
dedupKeytitle =~ /^(.+) (?:above|below) threshold$/ || title =~ /^Connection to (.+) is/

Alarm und Entwarnung teilen sich damit einen Dedup-Schlüssel (backend1 CPU, bei Verbindungsalarmen backend1), und die Entwarnung löst den Vorfall auf. Für Beszel selbst gibt es das fertige Beszel-Preset, das auch Container, Dienste, Akku, SMART und ZFS abdeckt.

Standard-Feld-Mapping

SelektorNormalisiertes FeldHinweise
title || messageTitelVersucht zuerst title, dann message
statusStatus: Werte in resolveValues lösen den Alarm auf, alles andere hält ihn offenStandard-resolveValues: resolved, closed
(standardmäßig keiner)SchweregradJeder Alarm nutzt den in der Source konfigurierten Standard-Schweregrad, bis du einen severity-Selektor und ein severityMap hinzufügst
(standardmäßig keiner)HostLeer, bis du einen host-Selektor hinzufügst
(standardmäßig keiner)Dedup-KeyFällt auf einen deterministischen Hash aus Titel + Host zurück, bis du einen dedupKey-Selektor hinzufügst

Beispiel-Payload

So sieht die Payload aus, die das Standard-Mapping direkt nach dem Anlegen erwartet:

{
  "title": "Disk usage above 90% on db-primary",
  "message": "Disk usage above 90% on db-primary",
  "status": "open"
}

Du kannst genau diese Payload über den Tab Payload Mapping im Dashboard gegen das Mapping deiner Source senden, eine gute Möglichkeit, das Standard-Mapping zu bestätigen, bevor du die Selektoren für dein echtes Tool anpasst.

Auf dieser Seite