Monitoring und Alerting¶
Niemand will den ganzen Tag Dashboards beobachten und darauf warten, dass etwas kaputtgeht. Die Plattform deployt ihr Alerting daher als Code und erzwingt es mit Azure Policy, sodass die Alerts, die existieren sollen, auch existieren und eine Benachrichtigung die Menschen erreicht, die handeln können.
Dieser Bereich erklärt, wie das Alerting funktioniert, welche Alerts es gibt und wie du das Routing von Alerts einrichtest (oder übernimmst).
Wer Alerts empfängt und bearbeitet, hängt von deinem Betriebsmodell ab. Im managed Modell ist der Empfänger die XMMS-Bereitschaftsroute. Im Eigenbetrieb ist es dein eigenes Plattform-Team.
Seiten in diesem Bereich¶
| Seite | Verwende sie, um |
|---|---|
| Wie Alerting funktioniert | Die Alert-initiatives, Severities, Action Groups, Processing Rules und die optionale 24/7-Route zu verstehen |
| Alert-Katalog | Zu sehen, was überwacht wird, nach Severity und Ressourcenbereich |
| Monitoring ausrollen | Die Plattform an dein On-Call-Tool anzubinden und das Alerting einzuschalten |
| Monitoring-Regeln (für einen spoke zuweisen oder entfernen) | Die Standard-Alert-Regeln eines spokes zu ändern |
| Monatlicher Health Check | Zu prüfen, dass die Alerts und ihre Policies vorhanden und nicht zu laut sind |
Monitoring und Observability¶
| Begriff | Bedeutung | In der Plattform |
|---|---|---|
| Monitoring | Bekannte Indikatoren (Verfügbarkeit, CPU, Durchsatz) erfassen und bei Schwellenwerten handeln | Metric- und Activity-Log-Alerts aus den Alerting-initiatives |
| Observability | Dem System neue Fragen stellen können, auch Fragen, die du nicht geplant hast | Logs und Metriken in Log Analytics, durchsuchbar und korrelierbar. Ein Dashboard-Tool obendrauf (zum Beispiel Grafana) bietet einen Einstiegspunkt und den Drill-down ins portal |
Alerts sagen dir, dass etwas Erwartetes eingetreten ist. Logs helfen dir herauszufinden, was du nicht erwartet hast. Nutze beides. Für eine erste Diagnose siehe Wo du zuerst nachsiehst.
Wer wofür verantwortlich ist¶
| Bereich | Verantwortlich | Hinweise |
|---|---|---|
| Hub-Alerts, Action Groups der Plattform, Routing | Plattform-Team | Die layers foundation, connectivity und postdeployment (Deployment-layers) |
| Standard-Alert-Regeln in den spoke-subscriptions | Das Plattform-Team deployt sie per Policy | Das workload-Team kann ihre Entfernung beantragen (Monitoring-Regeln) |
| Alerts für die Anwendung selbst | Workload-Team | Alert-Regeln, Action Groups und Dashboards auf dem eigenen Workspace des workloads (Deinen workload betreiben) |
| Die Menschen und das Tool, die Alerts empfangen | Wer den Service betreibt (Betriebsmodelle) | Kontaktlisten und Eskalation sind Platzhalter in deinem Vertrag oder deiner eigenen Richtlinie |
Das Prinzip dahinter: Das Team, das einen workload baut, ist für dessen gesamten Lebenszyklus verantwortlich, einschließlich seines Alertings. Die Plattform liefert eine Baseline, damit Teams nicht bei null anfangen.
Den Service messen: Beispielziele¶
Um zu beurteilen, ob die Plattform gesund ist, definiere einige Ziele, die messbar sind und zu Maßnahmen führen. Miss sie jeden Monat auf dieselbe Weise und berichte sie (Service Level Management).
| Ziel | Beschreibung | Beispielziel | Gemessen mit |
|---|---|---|---|
| Time to recovery | Mittlere Wiederherstellungszeit bei Incidents mit Severity 1 | 1 Stunde, zu Geschäftszeiten | Zeit von der Erkennung bis zur Lösung im Ticketsystem |
| Verfügbarkeit | Prozentsatz der Zeit, in der die Plattform verfügbar ist | Das Microsoft-SLA der Komponenten | Service Health |
| Deployment-Erfolgsrate | Anteil erfolgreicher Produktions-Deployments | 99 % | Erfolgsrate der pipelines |
Das sind Beispiele von einer managed Plattform, keine Defaults. Wähle eigene Ziele und lege fest, woher die Zahlen kommen. Ein Dashboard, das sie berichtet (zum Beispiel in Grafana), spart Zeit im monatlichen Review.