Monitoring und Alerting Minimum Viable

Ziel: Signal vor Vollständigkeit

Ein gutes MVP für Monitoring/Alerting liefert schnelle, verlässliche Signale zu Plattformstörungen – ohne Alarmflut. Es ist besser, 10 hochwertige Alerts zu haben als 200 unklare.

MVP-Bausteine

1) Plattform-Health und Control Plane

• Azure Service Health (Advisories/Incidents) für relevante Regionen/Services abonnieren.
• Subscription Activity Log Alerts für kritische Ereignisse (z. B. Policy-Changes, Role Assignments, Key Vault Firewall/Access Changes).

2) Zentrale Action Groups

• einheitliche Benachrichtigungskanäle (On-Call, Ticketing, ChatOps)
• klare Ownership (wer reagiert?)
• Eskalation (nach X Minuten)

3) Top-Alerts (typische Plattformbasis)

Beispiele für MVP-Alerts, die sich bewährt haben:

• VPN/ExpressRoute: Tunnel down / BGP down
• Firewall/NVA: CPU/SNAT/Throughput-Sättigung
• DNS: Resolver nicht erreichbar (wenn eigener Resolver/Private DNS Resolver betrieben wird)
• Key Vault: 4xx/5xx Peaks, Throttling, Access denied-Spitzen
• Storage: Availability/Success Rate, Auth failures

4) Runbooks und “Definition of Done”

Ein Alert ohne Runbook erzeugt Betriebsstress. Minimal:

• “Was bedeutet der Alert?” (Impact)
• “Was prüfe ich zuerst?” (3–5 Checks)
• “Wann eskalieren?” (Ownership)

Praktisch hilfreich ist ein fester Runbook-Rahmen, z. B.:

• Impact: Was ist kaputt, was ist betroffen?
• Scope: Welche Region/Subscription/VNet?
• Checks: 3–5 konkrete Prüfungen (Logs/Metriken/Statusseiten)
• Mitigation: kurzfristige Maßnahmen (Workarounds)
• Fix: nachhaltige Korrektur (IaC/Config)
• Follow-up: Wie verhindern wir Wiederholung (Policy/Monitoring/Guardrails)

Metrik vs. Log Alerts

• Metrik Alerts sind ideal für schnelle, robuste Signale.
• Log Alerts eignen sich für Muster (z. B. viele 403/401), sind aber anfälliger für Noise, wenn Query/Schwellwerte nicht gepflegt werden.

Startpunkt: MVP zuerst auf Metriken + Activity Log, Logs danach gezielt ergänzen.

Welche Alerts zuerst? (Golden Signals)

Wenn du priorisieren willst, orientiere dich an “Golden Signals”:

• Latency: Latenzsprünge (wo messbar)
• Traffic: unerwartete Drops/Spikes
• Errors: 4xx/5xx, Auth failures, Throttling
• Saturation: CPU/Memory/SNAT/Connection Limits

Das ist häufig wirksamer als eine Liste “pro Service alles”.

Noise-Management

• Standardisiere Schwellwerte, aber erlaube service-spezifische Ausnahmen.
• Nutze Dämpfung/Severity und Wartungsfenster.
• Prüfe Alerts regelmäßig: “Welche haben in 30 Tagen echten Wert geliefert?”