Alerts und Benachrichtigungen: PagerDuty, Opsgenie

Alerts und Benachrichtigungen: PagerDuty, Opsgenie

1) Warum eine separate alert-Plattform

• Routing über Dienste/Tags/Umgebungen.
• Eskalationen und Zeitpläne (Bereitschaftsdienst, Follow-the-Sun).
• Deduplizierung/Ereigniskorrelation.
• Ruhige Fenster (Wartung/Freeze) und Mute-Regeln.
• Integrationen mit Monitoring, CI/CD und ChatOps.

Unterstützung: SLO-Schwelle → Alert → Mensch/Maschine → Runbook → Rollback/Fix → Postmortem.

2) Signalmuster und Schweregrad (severity)

• critical (page) - SLO-Verletzung/Geldwegfehler (Ein-/Auszahlung), sinkende Verfügbarkeit, Burn-Rate.
• high (page/ticket) - signifikante Verschlechterung ohne expliziten SLO-Durchbruch.
• medium (Ticket) - Kapazität, Backdegradation, Retrai.
• low (Informationen) - Trends, Warnungen.

Regel: Seite nur per SLO oder expliziter Business Trigger.

3) Routing-Architektur

1. Quelle (Prometheus/Alertmanager, Grafana, Cloud Monitoring, eigene Webhooks).
2. Шлюз (PagerDuty/Opsgenie service/integration).
3. Richtlinien: Routen nach Tag ('service', 'env', 'region'), severity, payload.
4. Eskalationen: Abfolge von Dienstebenen (L1→L2→menedzher).
5. Kommunikation: ChatOps-Kanäle, Statusseiten, Mailings.

Beispiel für Key Tags (standardisieren)

„service“, „env“, „region“, „version“, „runbook“, „release _ id“, „route“, „tenant“ (wenn B2B/Multi-Tenant).

4) On-Call und Eskalationsfahrpläne

Schedules: primary/secondary, роли (SRE, DBRE, Sec).
Rotationen: Tag/Nacht, Follow-the-Sun, Wochenende.
Overrides: Urlaub/Krankheit.
Eskalationen: ack-timeout 5-10 min → die nächste Schicht. Während der Arbeitszeit - in der Profilabteilung; draußen ist ein On-Call-Spielplatz.

Tipp: Halten Sie kurze Eskalationsschritte in der Nacht (weniger Ermüdung) und länger am Tag (es gibt einen Kontext).

5) Integration mit Alertmanager (Grundmuster)

yaml receivers:
- name: pagerduty pagerduty_configs:
- routing_key: ${PAGERDUTY_ROUTING_KEY}
severity: '{{ if eq. Labels. severity "critical" }}critical{{ else }}error{{ end }}'
class: '{{.Labels. service }}'
component: '{{.Labels. env }}'
group: '{{.Labels. region }}'
description: '{{.Annotations. summary }}'
details:
service: '{{.Labels. service }}'
env: '{{.Labels. env }}'
runbook: '{{.Annotations. runbook }}'
release: '{{.Annotations. release }}'
route:
receiver: pagerduty group_by: ["service","env","region"]
group_wait: 30s group_interval: 5m repeat_interval: 2h

Opsgenie (webhook)

yaml receivers:
- name: opsgenie opsgenie_configs:
- api_key: ${OPSGENIE_API_KEY}
responders:
- name: "SRE Primary"
type: team priority: '{{ if eq. Labels. severity "critical" }}P1{{ else }}P3{{ end }}'
details:
trace: '{{.Labels. trace_id }}'
runbook: '{{.Annotations. runbook }}'

6) Rauschen, Dedup und Korrelation

Dedup-Schlüssel: Verwenden Sie einen stabilen Fingerabdruck (z. B. Service + Route + Code).
Gruppierung: 'group _ by' nach Service/Umgebung, damit die 5xx Kaskade nicht Dutzende von Seiten generiert.
Meets/Silent Windows: für die Dauer von Migrationen/Releases/Lasttests.
Unterdrückung aus dem Grund: Wenn es bereits einen P1-Vorfall für 'api-gateway @ prod' gibt, unterdrücken Sie die untergeordneten P2/P3.

Anti-Muster: CPU/Memory-Paging ohne bestätigten Einfluss auf SLO.

7) Verknüpfung mit Releases und Auto-Aktionen

Bei der kanarischen Deploy erhält PagerDuty/Opsgenie eine Alert vom SLO-Gate → Webhook in CI/CD → Pause/Rollback (Argo Rollouts/Helm).
Alert enthält: 'release _ id', 'image. tag', Link zur Pipeline und zum Runbook des Rollback-Schritts.

Beispiel für einen Link-Runbook in Anmerkungen

runbook: https://runbooks. company/rollback/api-gateway#canary

8) ChatOps und Kommunikation

Automatische Erstellung eines Incident-Kanals in Slack/Teams, Verknüpfung mit einem Ticket.
Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.
Status-Seite: Automatische Aktualisierung bei P1/P2.

9) Lebenszyklus des Vorfalls (Minimum)

1. Trigger (alert von SLO/Sensoren).
2. Page (primary on-call).
3. Ack (Bestätigung, TTA).
4. Kommunikation (Kanal/Status).
5. Mitigate (Rollback/Feature-Flag/Isolation).
6. Resolve (TTR).
7. Postmortem (Zeitlinie, Ursachen, Aktionen, Lektionen, Aufgabeninhaber).

Role-kit: IC (incident commander), Ops lead, Comms, Scribe.

10) Nützliche Felder von payload (normalize)

json
{
"service": "payments-api",
"env": "prod",
"region": "eu-central-1",
"severity": "critical",
"event_class": "slo_burn",
"summary": "Withdraw 5xx > 0. 5% for 10m",
"runbook": "https://runbooks/payments/withdraw-5xx",
"release_id": "rel-2025-11-03-14-20",
"image": "ghcr. io/org/payments:1. 14. 2",
"trace_id": "8a4f0c2e9b1f42d7",
"annotations": { "canary": "25%" }
}

11) Integration von Signalquellen

Prometheus/Alertmanager ist die Hauptquelle von SLO/RED.
Grafana Alerting - einfacher für Dashboards/Business-Metriken.
OpenTelemetry/SpanMetrics - Latenz/Fehler entlang der Routen.
K8s-Ereignisse - Cluster-Crashs (Control-Plane, PDB-Störungen).
DB/Queues - lag/locks/replication.
App-Webhooks - Domain-Signale (PSP-Fehler, Betrugsschub).

12) Richtlinien und Compliance

RBAC zum Erstellen/Ändern von Richtlinien, Zeitplänen, Mutes.
Audit: Wer hat den Status, die Zeitstempel, anerkannt/zugewiesen/geändert.
PII-Minimierung in den Pailoads (Ticket-ID statt Email/Telefon des Nutzers).
DR-Plan: Was tun, wenn PagerDuty/Opsgenie nicht verfügbar ist (Fallback-Kanal).

13) Praxisbeispiele (PagerDuty vs Opsgenie)

14) Ruhige Fenster und Frost

Freeze: Verbot von Paging in geplanten Release-Fenstern, so dass nur P1 übrig bleibt.
Jut nach den Tags: 'env = stage', 'region = dr', 'service = batch'.
Temporär mute: bei DB Migration/Loadtests - mit explizitem Besitzer.

15) Leistungsmetriken (SRE/DORA für Alert)

MTTA/MTTR (im Rahmen von Befehlen/Diensten/Schichten).
% Alert mit Runbook (Ziel ≥ 95%).
Anteil der Page Alert nach SLO (Ziel ≥ 90%).
Verhältnis nützlich/laut (Ziel ≥ 3:1).
% Auto-Aktivitäten (Pause/Rollback über Webhook) - wachsen.
Burn-down postmortem Aktionsgegenstände in 14/30 Tagen.

16) Anti-Muster

Paige auf der „Hardware“ (CPU, Festplatte), ohne den Benutzer zu beeinflussen.
Das Fehlen von „group _ by“ → der „Sturm“ der Alert.
Keine leisen Fenster - die Releases färben alles rot.
Payloads ohne' service/env/runbook'- es ist unmöglich zu routen/handeln.
Es gibt keine einheitliche Skala von Severity und Regeln (jede Quelle - auf ihre eigene Weise).
„Ewige“ Warnungen, die niemand repariert (Alert-Pflicht).

17) Checkliste Umsetzung (0-45 Tage)

0-10 Tage

Harmonisierung der Severity-Skala und Standardisierung der Tags/Anmerkungen.
Erstellen Sie Dienste in PagerDuty/Opsgenie, konfigurieren Sie Zeitpläne und grundlegende Eskalationen.
Binden Sie Alertmanager/Grafana ein, aktivieren Sie' group _ by 'und dedup.

11-25 Tage

Geben Sie SLO-Alerts (Multi-Window-Burn) ein, fügen Sie einen Runbook-Link hinzu.
ChatOps einrichten: Auto-Channels, ack/assign-Befehle.
Aktivieren Sie stille Fenster für Releases/Migrationen.

26-45 Tage

Integrieren Sie Auto-Pause/Rollback für Kanarienvögel (Webhooks).
Einführung von MTTA/MTTR-Berichten und Allert-Hygiene (Geräuschreinigung).
Standardisieren Sie Postmortem und Kontrolle über Aktionselemente.

18) Fertige Snippets

Grafana Alerting → PagerDuty (JSON Body Mupping)

json
{
"routing_key": "${PAGERDUTY_ROUTING_KEY}",
"event_action": "trigger",
"payload": {
"summary": "{{.RuleName }}: {{ index. Labels \"service\" }}",
"severity": "{{ if eq (index. Labels \"severity\") \"critical\" }}critical{{ else }}error{{ end }}",
"source": "grafana",
"component": "{{ index. Labels \"env\" }}",
"group": "{{ index. Labels \"region\" }}"
},
"links": [
{ "href": "{{.DashboardURL }}", "text": "Dashboard" },
{ "href": "{{ index. Labels \"runbook\" }}", "text": "Runbook" }
]
}

Webhook aus dem Alert → Argo Rollouts Pause

bash curl -X POST "$ARGO_API/rollouts/pause" \
-H "Authorization: Bearer $TOKEN" \
-d '{"name":"api-gateway","namespace":"prod"}'

Opsgenie - Routing-Regel (Pseudo)

yaml if:
tags: ["service:payments","env:prod"]
severity: ["P1","P2"]
then:
route_to: "SRE-Payments"
notify: ["Primary OnCall","Secondary"]

19) Schlussfolgerung

Eine starke Alert-Schaltung ist ein Prozess + Disziplin: SLO-orientierte Schichtung, kompetentes Routing und Eskalationen, einheitliche Tags und Pailoads, leise Fenster, ChatOps und automatische Aktionen (Pause/Rollback). Wählen Sie PagerDuty oder Opsgenie für Budget und UX, aber halten Sie sich an die gleichen Lärm-, Dienst- und Haftungsregeln - dann ist die Seite selten, genau und nützlich und die Vorfälle sind kurz und überschaubar.