Monitoring
Kurzzusammenfassung
- Monitoring ist das verbindliche Control-Framework für Daten-, Modell- und Betriebsrisiken im Live-Betrieb.
- Alle Metrikfamilien haben feste Frequenzen, klare Owner und dokumentierte Eskalationspfade.
- Einheitliche Mindestmetriken reduzieren Blind Spots und beschleunigen Incident-Reaktion.
- Das Framework liefert die operative Evidenz für
ServiceTask_Monitorund nachgelagerte Alerts/Drift-Entscheide.
Ziel
Business-Nutzen: Das Monitoring-Framework stellt sicher, dass Qualitäts-, Stabilitäts- und Verfügbarkeitsrisiken früh erkannt und in reproduzierbare Gegenmassnahmen überführt werden.
Verbindliche Metrikfamilien
| Metrikfamilie | Pflichtmetriken (Mindeststandard) | Frequenz | Primary Owner | Secondary Owner |
|---|---|---|---|---|
| Daten | Freshness-Lag, Vollständigkeit (%), Schema-Drift, Null-/Outlier-Rate | je Pipeline-Run + täglicher Summary-Check | Data Engineering | Data Owner Fachdomäne |
| Modell | Primäre Zielmetrik (z. B. Precision/Recall/IR), Kalibrierung, Fehlersegmentierung, Inferenz-Driftindikator | stündlich Aggregat + täglicher Performance-Review | MLOps | Model Owner |
| Betrieb | p95/p99-Latenz, Error Rate, Throughput, Availability/SLO, Queue-Lag | kontinuierlich (1-5 Min) + Schichtübergabe | Platform Ops | Incident Manager |
Ablauf
| Schritt | Mechanik | Ergebnis |
|---|---|---|
| Signale erfassen | Telemetrie aus Pipelines, Serving, Feature Store, Modellmonitoring | Konsolidierte Zeitreihen je Metrikfamilie |
| Baselines vergleichen | Ist-Werte gegen SLOs, historische Baseline und Release-Baseline prüfen | Abweichung als Warnung/Incident klassifiziert |
| Massnahmen auslösen | Alerting, Incident-Runbook, ggf. Drift-Deep-Dive oder Retrain-Prüfung | Kontrollierte Reaktion mit dokumentierter Ownership |
Kontrollen
Governance- und Risiko-Aspekte
- Für jede Pflichtmetrik sind Messmethode, Frequenz und Owner versioniert dokumentiert.
- Änderungen an Schwellenwerten erfolgen nur per Change-Record mit Begründung und Freigabe.
- Monitoring-Entscheide sind mit Alerting, Drift-Analyse und Decision Logging durchgängig verknüpft.
Operative Checks
| Check | Monitoring | Verantwortlich | Eskalation |
|---|---|---|---|
| Daten-Mindestset vollständig | je Run automatisiert + tägliche manuelle Plausibilisierung | Data Engineering | Data Owner → Incident Channel |
| Modell-Mindestset stabil | stündlicher Trendcheck + täglicher Review | MLOps + Model Owner | ML Lead → Governance Board |
| Betriebs-Mindestset SLO-konform | 1-5 Min Metrikscan + 24/7 On-Call | Platform Ops | Incident Commander |
Entscheidung
- Alle drei Metrikfamilien (Daten, Modell, Betrieb) sind mit Pflichtmetriken, Frequenz und Owner hinterlegt.
- Für jede Pflichtmetrik existieren Schwellwerte und ein verlinktes Runbook.
- Wiederholte Grenzwertverletzungen führen zu dokumentierter Ursachenanalyse und Massnahmenplan.
BPMN-Detailansicht
⋮⋮⋮
BPMN-Kontext
- IDs:
ServiceTask_Monitor, Gateway_Retrain - Input-Bezug: Laufende Betriebs-, Drift- und Performance-Metriken je Metrikfamilie.
- Entscheidungsbezug: Monitoring bewertet Schwellwerte und liefert Trigger für
Gateway_Retrain. - Output-Bezug: Priorisierte Alerts, Drift-Tickets und evidenzbasierte Entscheidungsgrundlage.