Prometheus Alertmanager

Überblick

Die Alertmanager-Integration leitet Statusänderungen eines Monitors an eine Instanz von Prometheus Alertmanager weiter. Bei jeder Änderung sendet OKStatus ein POST an ‹ihre-url›/api/v2/alerts, und Alertmanager verteilt es an die von Ihnen konfigurierten Empfänger (E-Mail, Slack, PagerDuty …).

Verfügbar ab dem Tarif Pro.

Was OKStatus sendet

Ein Alarm je Statusänderung, im Alertmanager-v2-Format:

Feld	Wert
labels.alertname	OKStatusMonitorDown
labels.severity	critical (down) · warning (beeinträchtigt) · info (up / pausiert)
labels.monitor	Name des Monitors
labels.region	Region, aus der die Prüfung lief
labels.status	down · degraded · up · paused
labels.source	okstatus
annotations.summary	Beschreibung in Klartext
annotations.target	Die überwachte URL

• Auslösende Alarme (down, degraded) werden ohne endsAt gesendet.
• Auflösende Alarme (up, paused) werden mit endsAt auf jetzt gesendet, was den Alarm in Alertmanager schließt.

Routen Sie über das Label source="okstatus", um OKStatus-Alarme vom Rest Ihrer Alarmierung zu trennen.

Einrichtung

1. Gehen Sie in OKStatus zu Alarmierung → Kanäle.
2. Klicken Sie auf Kanal hinzufügen → Alertmanager / Prometheus.
3. Geben Sie die Basis-URL Ihres Alertmanagers ein — nicht den Pfad /api/v2/alerts, den hängt OKStatus selbst an.
4. (Optional) Ergänzen Sie Basic-Auth-Zugangsdaten, falls Ihr Alertmanager geschützt ist.
5. Klicken Sie auf Testen und hängen Sie den Kanal dann an Ihre Monitors.

Selbst gehosteter Alertmanager im Cluster

Sie können OKStatus auf einen Alertmanager richten, der im selben Kubernetes-Cluster läuft. Verwenden Sie den DNS-Namen des Service und achten Sie auf diese drei Punkte:

1. Den DNS-Namen verwenden, nicht die ClusterIP. Aus Sicherheitsgründen lehnt OKStatus URLs ab, die auf eine buchstäbliche private/reservierte IP auflösen (z. B. 10.x, 192.168.x) — ein clusterinterner DNS-Name wie *.svc.cluster.local wird jedoch akzeptiert.
2. Den Port angeben — Alertmanager lauscht auf 9093, nicht auf 80.
3. Nur die Basis-URL eingeben — /api/v2/alerts ergänzt OKStatus.

Über Namespaces hinweg funktioniert der vollqualifizierte Name, zum Beispiel:

http://alertmanager.monitoring.svc.cluster.local:9093

Auf einen Service mit Endpoints zeigen

Ein Headless Service ohne bereite Pods (0 Endpoints) löst auf nichts auf, das Senden schlägt also mit ENOTFOUND / „nicht erreichbar” fehl, obwohl die URL richtig aussieht. Prüfen Sie, ob Ihr Ziel Endpoints hat:

kubectl get endpoints <alertmanager-service> -n <namespace>

Führt der Befehl keine Adressen auf, wählen Sie stattdessen den Service, der die laufenden Alertmanager-Pods bedient.

Testen

Die Schaltfläche Testen sendet einen einzelnen auslösenden Alarm OKStatusMonitorDown (Labels wie oben, monitor="Test Monitor", region="TEST").

Die Erreichbarkeit lässt sich auch aus dem Cluster heraus prüfen, aus dem Namespace, in dem OKStatus läuft:

kubectl run amtest --rm -i --restart=Never --image=curlimages/curl \
  -n <okstatus-namespace> -- \
  curl -s -o /dev/null -w '%{http_code}\n' \
  -X POST http://alertmanager.monitoring.svc.cluster.local:9093/api/v2/alerts \
  -H 'Content-Type: application/json' -d '[]'

Ein 200 bedeutet, dass Alertmanager die Payload angenommen hat.

Wie es sich zeigt

• In der Alertmanager-Oberfläche → Alerts erscheint der Test als auslösende Gruppe alertname="OKStatusMonitorDown". Da der Test einmalig gesendet wird, löst Alertmanager ihn nach seinem resolve_timeout (standardmäßig 5 Minuten) automatisch auf — er ist also nur kurz sichtbar. Öffnen Sie die Oberfläche direkt nach dem Test oder filtern Sie auf source="okstatus".
• Bei Ihren Empfängern (E-Mail, Slack …) kommt er als normale Benachrichtigung an und bleibt dort — die verlässlichste Bestätigung, dass die Kette funktioniert.
• Ein echter ausgefallener Monitor sendet bei jeder fehlgeschlagenen Prüfung erneut, sein Alarm bleibt in Alertmanager also durchgehend auslösend, bis der Monitor sich erholt — dann sendet OKStatus die Auflösung und Alertmanager markiert ihn als resolved.

Fehlersuche

Symptom	Ursache / Abhilfe
„nicht erreichbar” / ENOTFOUND	Falscher Hostname, oder der Service hat 0 Endpoints — kubectl get endpoints prüfen.
„nicht erreichbar” / ECONNREFUSED	Falscher Port — :9093 verwenden.
„private oder reservierte IP-Adresse”	Sie haben eine rohe ClusterIP verwendet — nehmen Sie den DNS-Namen des Service.
200, aber nichts bei den Empfängern	Alertmanager hat es erhalten, aber keine Route passt — Route auf source="okstatus" ergänzen.
Test lief einmal, danach nichts in der Oberfläche	Erwartet: Der einmalige Testalarm löst sich nach resolve_timeout selbst auf.
Lokal funktioniert es, aus dem Cluster nicht	Eine NetworkPolicy blockiert womöglich den Egress aus dem OKStatus-Namespace.