Monitoring
Die kontinuierliche Überwachung von KI-Systemen in Produktion, um Performance-Probleme, Datenänderungen und Modellverschlechterung frühzeitig zu erkennen.
Die drei Säulen der Service-Zuverlässigkeit – SLI misst, SLO definiert Ziele, SLA ist der Vertrag. Grundlage für Reliability Engineering.
SLI, SLO und SLA sind die drei Ebenen, um Service-Zuverlässigkeit zu definieren und zu messen.
Die Hierarchie:
SLA (Service Level Agreement)
│ "Wir garantieren 99.9% Verfügbarkeit, sonst Gutschrift"
│ → Vertrag mit Kunden, rechtlich bindend
│
└── SLO (Service Level Objective)
│ "Unser internes Ziel: 99.95% Verfügbarkeit"
│ → Strenger als SLA, gibt uns Puffer
│
└── SLI (Service Level Indicator)
"Gemessene Verfügbarkeit letzte 30 Tage: 99.97%"
→ Die tatsächliche Messung
Beispiel für eine API:
| Typ | Beispiel |
|---|---|
| SLI | Latenz P99 = 145ms |
| SLO | Latenz P99 soll unter 200ms sein |
| SLA | Latenz P99 unter 500ms, sonst 10% Gutschrift |
| Kategorie | SLI | Messung |
|---|---|---|
| Verfügbarkeit | Erfolgreiche Requests / Alle Requests | Prozent |
| Latenz | Antwortzeit P50, P95, P99 | Millisekunden |
| Durchsatz | Requests pro Sekunde | RPS |
| Fehlerrate | Fehler / Alle Requests | Prozent |
| Korrektheit | Korrekte Antworten / Alle Antworten | Prozent |
# slo.yaml
slos:
- name: api-availability
description: "API sollte verfügbar sein"
sli:
type: availability
good_events: "http_status < 500"
total_events: "all requests"
objective: 99.9%
window: 30d
- name: api-latency
description: "API sollte schnell antworten"
sli:
type: latency
threshold: 200ms
percentile: 99
objective: 99%
window: 30d
SLO: 99.9% Verfügbarkeit über 30 Tage
Error Budget = 100% - 99.9% = 0.1%
= 0.1% × 30 Tage × 24h × 60min
= 43.2 Minuten Downtime erlaubt
Aktueller Verbrauch:
- Incident 1: 15 Minuten
- Incident 2: 10 Minuten
- Verbraucht: 25 Minuten (58%)
- Übrig: 18.2 Minuten (42%)
# Verfügbarkeit SLI
- record: sli:api_availability:ratio
expr: |
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# Latenz SLI (P99 unter 200ms)
- record: sli:api_latency:ratio
expr: |
sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))
# Alert wenn Error Budget zu schnell verbraucht wird
groups:
- name: slo-alerts
rules:
- alert: ErrorBudgetBurnRate
expr: |
(
1 - sli:api_availability:ratio
) > 14.4 * (1 - 0.999)
for: 5m
labels:
severity: critical
annotations:
summary: "Error Budget wird zu schnell verbraucht"
| Verfügbarkeit | Downtime/Jahr | Downtime/Monat |
|---|---|---|
| 99% (zwei 9) | 3.65 Tage | 7.3 Stunden |
| 99.9% (drei 9) | 8.76 Stunden | 43.8 Minuten |
| 99.95% | 4.38 Stunden | 21.9 Minuten |
| 99.99% (vier 9) | 52.6 Minuten | 4.38 Minuten |
| 99.999% (fünf 9) | 5.26 Minuten | 26.3 Sekunden |
SLI ist wie ein Thermometer (misst Temperatur), SLO ist wie die Wunschtemperatur (20°C), SLA ist wie der Mietvertrag (Vermieter garantiert funktionierende Heizung, sonst Mietminderung).
SLI (Indicator): Was messen wir? (z.B. Latenz, Verfügbarkeit)
SLO (Objective): Was ist unser Ziel? (z.B. 99.9% Verfügbarkeit)
SLA (Agreement): Was versprechen wir Kunden? (mit Konsequenzen)
API-Services
Latenz und Verfügbarkeit für externe APIs garantieren
ML-Inference
Antwortzeiten und Accuracy für Modell-Endpoints
Cloud-Dienste
AWS, GCP, Azure haben SLAs für ihre Services
Enterprise-Verträge
Vertragliche Zusagen an Geschäftskunden
SLO ist intern (unser Ziel). SLA ist extern (Vertrag mit Kunden). SLOs sollten strenger sein als SLAs, um Puffer zu haben.
99% = 3.65 Tage Downtime/Jahr. 99.9% = 8.76 Stunden. 99.99% = 52 Minuten. Mehr 9en = exponentiell teurer. Wähle basierend auf Business-Anforderungen.
Die erlaubte Fehlerquote. Bei 99.9% SLO hast du 0.1% Error Budget. Wenn aufgebraucht: Keine neuen Features, nur Stabilität.