Webhook
Was es tut: Jedes System, das einen Webhook aufrufen kann, meldet seine Alarme an eine eigene Adresse. Tenvima zeigt sie unter Hub → Alarme als Quelle Systeme. Meldet das System den Alarm als behoben, erledigt Tenvima ihn. Auf diese Alarme reagieren die Workflows des Hubs.
Sie brauchen: das Recht Alarmquellen per Webhook anbinden.
- Öffnen Sie Hub → Katalog → Webhook und klicken Sie auf Quelle anbinden.
- Geben Sie einen Name ein, etwa „Uptime Kuma Rechenzentrum“, und wählen Sie das Format. Betreffen alle Alarme der Quelle einen Kunden, wählen Sie ihn unter Kunde (optional); es muss ein Kunde aus Ihrer Kundenliste sein.
- Klicken Sie auf Anbinden. Die neue Quelle öffnet sich daneben; kopieren Sie die Webhook-Adresse. Tenvima zeigt sie nur jetzt.
- Tragen Sie die Adresse im System ein, wie unten beschrieben.
Jede Quelle steht als Zeile mit Format, Kunde, letztem Eingang und ihren offenen Alarmen. Der Punkt an ihrem Zeichen zeigt Wartet, bis zum ersten Mal etwas ankommt, dann Empfängt oder Gestört mit dem Grund. Ein Klick öffnet die Quelle daneben mit Neue Adresse, Ändern, Trennen und ihren Letzten Lieferungen; dieselben Befehle stehen im Menü … der Zeile. Alles, was ankam, steht im Protokoll. Im Datenfluss ist jede Quelle eine eigene Karte.
Uptime Kuma
Abschnitt betitelt „Uptime Kuma“- Einstellungen → Benachrichtigungen: eine Benachrichtigung vom Typ „Webhook“ anlegen.
- Die Adresse als Post URL, Request Body
application/json. - Bei den Monitoren einschalten und testen.
Ein Monitor, der ausfällt, wird ein Alarm Kritisch, einer im Status „pending“ Geringfügig. Kommt er wieder, ist der Alarm erledigt.
Grafana
Abschnitt betitelt „Grafana“- Alerting → Contact points: einen Kontaktpunkt mit der Integration „Webhook“ anlegen.
- Die Adresse als URL, Methode POST.
- Den Kontaktpunkt in einer Notification Policy wählen.
Alertmanager
Abschnitt betitelt „Alertmanager“receivers: - name: tenvima webhook_configs: - url: "<Adresse>" send_resolved: trueroute: receiver: tenvimaDanach die Konfiguration neu laden. Bei Grafana und Alertmanager bestimmt das Label severity den Schweregrad, etwa critical oder warning.
Eigenes JSON
Abschnitt betitelt „Eigenes JSON“Für Backup-Jobs, Skripte und alles andere. Senden Sie per POST einen Alarm oder { "alarms": [...] }:
| Feld | Pflicht | Inhalt |
|---|---|---|
key |
ja | bleibt für denselben Alarm gleich, etwa backup/fs01 |
title |
ja | was in der Liste steht |
state |
raised (Standard) oder cleared |
|
severity |
critical, major (Standard), minor oder info |
|
detail |
weiterer Text | |
at |
Zeitpunkt, etwa 2026-11-12T08:00:00Z; einer in der Zukunft gilt als jetzt |
curl -X POST '<Adresse>' \ -H 'Content-Type: application/json' \ -d '{"key":"backup/fs01","title":"Backup fs01 fehlgeschlagen","severity":"critical"}'Derselbe key mit "state": "cleared" erledigt den Alarm.
Sicherheit
Abschnitt betitelt „Sicherheit“Die Adresse ist der Schlüssel; wer sie kennt, kann Alarme einliefern. Neue Adresse ersetzt die alte sofort; tragen Sie sie gleich im System ein. Trennen beendet die Quelle, ihre offenen Alarme werden erledigt.
Grenzen
Abschnitt betitelt „Grenzen“- 100 Alarme je Aufruf. Was darüber hinausgeht, fällt weg; das Protokoll nennt es als Warnung.
- 500 offene Alarme und 100 neue je Stunde je Quelle. Darüber nimmt Tenvima keine neuen Alarme der Quelle an und antwortet mit
429. Was schon offen ist, wird weiter aufgehoben und erneut gemeldet. Die Quelle steht dann auf Gestört mit dem Satz „Die Quelle meldet zu viele neue Alarme …“; hält das an, erscheint in der Alarmliste Verbindung gestört. Beides verschwindet, sobald Tenvima einen Aufruf wieder ganz annimmt. - Unlesbarer Aufruf. Passt ein Aufruf nicht zum Format, antwortet Tenvima mit
400und nennt den Grund im Protokoll, etwa „Der Aufruf ist kein lesbares „Uptime Kuma“: Das Feld heartbeat fehlt.“ Die Quelle bleibt dabei in Ordnung.