Zum Inhalt

Monitoring ausrollen

Nutze dieses Runbook, wenn du das Alert-Routing für eine Plattform zum ersten Mal einrichtest, wenn du es auf ein anderes On-Call- Tool umstellst oder wenn du eine Plattform übernimmst (Day-one-Checkliste). Am Ende erreichen Alerts der Severity 0 bis 2 die Menschen, die Incidents bearbeiten, und die Alert-Policies sind zugewiesen.

Hintergrund steht unter Wie Alerting funktioniert. Die Beispiele nutzen ein On-Call-Tool, das aus einem Webhook einen Incident öffnet und ihn in einem Chat-Kanal postet. Jedes Tool mit Webhook-Empfänger funktioniert.

Bevor du anfängst

Entscheidung Optionen
Wer Alerts erhält Das Plattform-Team (XMMS oder dein eigenes Team)
Wann Nur zu Geschäftszeiten oder auch außerhalb der Bürozeiten (24/7). 24/7 ist im Managed-Modell eine Vertragsfrage
Welches Tool Dein Incident- oder On-Call-Tool. Es muss einen Webhook annehmen und bei kritischen Alerts eine Person anrufen oder ihr eine SMS schicken können
Welcher Chat-Kanal Ein Kanal pro Plattform oder Kunde für den Incident-Feed
Empfänger pro Umgebung canary kann an einen Testkanal senden. prod sendet an die echte Route

Führe die Änderung über den normalen Änderungs-Workflow durch: Branch, pull request, canary, prod.

1. Den Service im On-Call-Tool erstellen

  1. Wenn deine Organisation Services nach Kunde oder Plattform gruppiert, erstelle zuerst diese Gruppierung.
  2. Erstelle einen Service für die Plattform. Wähle eine Eskalations-Policy, die zu den vereinbarten Zeiten passt (zum Beispiel eine Policy für Geschäftszeiten oder eine 24/7-Policy).
  3. Füge auf dem Tab Integrations eine Integration für Microsoft Azure hinzu (oder einen generischen Webhook, wenn das Tool keine Azure- Integration hat).
  4. Kopiere die Integrations-URL. Behandle sie als Secret: Jeder, der sie hat, kann Incidents erstellen.

2. Den Chat-Kanal verbinden (optional)

  1. Erstelle einen Kanal für die Plattform-Alerts, intern für das Plattform-Team.
  2. Öffne im On-Call-Tool den Service und füge eine Erweiterung oder Verbindung für dein Chat-Tool hinzu.
  3. Verbinde den Service mit dem Kanal. Prüfe, dass dort ein Test-Event ankommt.

3. Den Empfänger in die Konfiguration eintragen

Setze die Empfänger der Action Groups der Plattform in <primary region>/foundation.auto.tfvars jedes Ordners einer Plattform- Umgebung. Die allgemeine Action Group bezieht ihren Webhook aus monitor_action_group_general_webhook_receiver. Die Action Group, die die Alerts der landing zone empfängt, hat eigene Variablen (monitor_action_group_xpirit_*). Setze beide, sonst routest du nur einen Teil der Alerts (Hub-Konfiguration).

monitor_action_group_general_webhook_receiver = {
  "Webhook Receiver - <platform name> Hub (Production)" = {
    name                    = "Webhook Receiver - <platform name> Hub (Production)"
    service_uri             = "https://<on-call tool>/integration/<integration-key>/enqueue"
    use_common_alert_schema = true
    aad_auth                = null
  }
}
Feld Wert
Map-Key und name Ein lesbarer Name. Nutze einen pro Umgebung und sage, welcher canary und welcher prod ist
service_uri Die Integrations-URL aus Schritt 1
use_common_alert_schema true. Das On-Call-Tool erhält das Common Alert Schema
aad_auth null, es sei denn, dein Empfänger validiert ein Entra-ID-Token

Committe keine geheime URL in ein Repository, das viele Personen lesen können, wenn deine Policy das verbietet. Prüfe, wo dein Konfigurations-Repository solche Werte ablegt und wer sie lesen kann.

E-Mail-Empfänger setzt du auf dieselbe Weise (monitor_action_group_general_email_receiver und die passende Variable der zweiten Gruppe). Nutze ein Gruppenpostfach, keine Einzelperson.

4. Anwenden

  1. Öffne einen pull request und prüfe den Plan. Der layer foundation sollte nur Änderungen an den Action Groups zeigen.
  2. Wende auf canary an, prüfe die Action Groups im Portal (Monitor > Alerts > Action groups) und wende dann auf prod an.

5. Die Alert-Initiatives zuweisen

Prüfe alerting_management_groups in <primary region>/postdeployment.auto.tfvars: Die Keys cloudplatform und landingzones sind erforderlich, und jedes Flag deploy_alerting_* schaltet eine Initiative ein. Siehe Monitoring-Regeln.

Führe hub aus. Starte für bestehende Subscriptions Remediation Tasks, damit die Regeln für bestehende Ressourcen erstellt werden (die Standardregeln zuweisen).

6. Optional: die hub-24/7-Route

Wenn Alerts außerhalb der Geschäftszeiten für den hub in deinem Service enthalten sind, aktiviere hub_247_support mit einem eigenen Webhook (und einer anderen Integration im On-Call-Tool, mit eigener Eskalations-Policy). Einstellungen und Defaults: Monitoring-Regeln.

Verifizieren

  1. Regeln existieren. Im Portal unter Monitor > Alerts > Alert rules, gefiltert auf eine Plattform-Subscription.
  2. Die Policy ist konform. Policy > Compliance für die Alert-Initiatives. Behebe, was nicht konform ist.
  3. Eine Nachricht kommt an. Löse ein Test-Event im On-Call-Tool aus oder warte auf den nächsten Service-Health- oder Resource-Health- Alert und prüfe, dass der Incident erscheint, dass er im Chat-Kanal gepostet wird und dass ein kritischer die On-Call-Person auf dem vereinbarten Weg erreicht (Anruf und SMS).
  4. Die Eskalation funktioniert. Prüfe, dass ein nicht bestätigter kritischer Incident wie vereinbart eskaliert.
  5. Halte es fest. Schreibe die Empfänger, die Zeiten und den Verantwortlichen der Integration an dem Ort auf, an dem dein Team seine Plattform-Dokumentation pflegt.

Betrieb

  • Prüfe Alerts wöchentlich, justiere Schwellenwerte, die zu viel Rauschen machen, und kontrolliere die Empfänger, wenn Personen dazukommen oder gehen (Das Alerting gesund halten).
  • Rotiere die Integrations-URL, wenn sie geleakt ist, und aktualisiere die Konfiguration wie oben beschrieben.
  • Halte für jeden Alert der Severity 0 ein Runbook bereit (Alert-Katalog).

Zurückrollen

Entferne oder ändere den Empfänger in der tfvars-Datei und führe hub erneut aus. Die Alert-Regeln bleiben, aber Benachrichtigungen hören auf, also informiere zuerst die Personen, die sich darauf verlassen.