Zum Inhalt

check-slo

Prueft die Betriebsstabilitaets-Konfiguration auf NFR-007-Konformitaet: SLI/SLO-Definitionen in Prometheus/Alertmanager, Circuit-Breaker-Pattern, Graceful-Degradation, Health-Endpoints. Nutze diesen Skill beim Setup von Monitoring oder nach Aenderungen an der Infrastruktur.

SLO/Monitoring-Check (NFR-007): $ARGUMENTS

Schritt 1: Monitoring-Dateien laden

Suche die relevanten Dateien parallel:

  1. Prometheus-Alerts: Glob helm/**/alerting-rules*.yaml oder monitoring/alerts/*.yaml
  2. Grafana-Dashboards: Glob monitoring/dashboards/*.json
  3. Health-Endpoints: Grep health in src/backend/app/api/v1/*/router.py
  4. Circuit-Breaker: Grep circuit_breaker\|CircuitBreaker\|tenacity in src/backend/
  5. NFR-007-Referenz: Lies spec/nfr/NFR-007_Betriebsstabilitaet-Monitoring.md erste 80 Zeilen

Schritt 2: SLO-Compliance pruefen

Pflicht-SLOs aus NFR-007 §2.2:

SLO Ziel Prüfe in Prometheus-Config
Verfügbarkeit ≥ 99,5% Alert bei probe_success < 0.995
Latenz P50 < 200ms Alert bei histogram_quantile(0.5,...) > 0.2
Latenz P95 < 500ms Alert bei histogram_quantile(0.95,...) > 0.5
Latenz P99 < 1.000ms Alert bei histogram_quantile(0.99,...) > 1.0
Error Rate < 1% Alert bei rate(5xx) / rate(all) > 0.01
Throughput ≥ 50 req/s Alert bei rate(requests[5m]) < 50

Prüfe ob fuer jedes SLO eine entsprechende Prometheus-Alert-Rule existiert.

Schritt 3: Health-Endpoints pruefen

Pflicht-Endpoints (NFR-007 §2.1, NFR-002 §3.3):

# MUSS vorhanden sein:
GET /health/live   # Liveness — ist der Prozess am Leben?
GET /health/ready  # Readiness — kann Traffic entgegengenommen werden?

# SOLLTE vorhanden sein:
GET /health/startup  # Startup-Probe fuer langsam startende Komponenten

Prüfe: - Liefern die Endpoints strukturierte JSON-Responses (nicht nur {"status": "ok"})? - Checken sie ArangoDB/Redis-Konnektivitaet bei /health/ready? - Sind sie in den Kubernetes-Probes konfiguriert?

Schritt 4: Resilience-Pattern pruefen

Circuit Breaker (NFR-007 §4):

# SOLLTE fuer ArangoDB/Redis-Calls vorhanden sein:
# tenacity-basierter Retry mit exponential backoff
# oder eigene CircuitBreaker-Implementierung

@retry(
    wait=wait_exponential(min=1, max=10),
    stop=stop_after_attempt(3),
    reraise=True
)
async def _query_with_retry(self, ...): ...

Prüfe: - Gibt es Retry-Logik fuer externe Datenbank-Calls? - Gibt es Timeouts bei ArangoDB/Redis-Verbindungen? - Gibt es Fallback-Behavior bei DB-Ausfall (z.B. Cache-only Mode)?

Schritt 5: Alerting-Eskalation pruefen

Prüfe die Alertmanager-Konfiguration auf 3 Schweregrade:

Schweregrad Reaktionszeit Route
critical < 15 Min PagerDuty / SMS (On-Call)
warning < 4 Stunden Slack / E-Mail
info Naechster Arbeitstag Ticket-System

Schritt 6: Report ausgeben

# SLO/Monitoring-Review: {Komponente}

## Health-Endpoints
{/health/live: ✅/❌ | /health/ready: ✅/❌ | DB-Check: ✅/❌}

## SLO-Alert-Coverage
{Tabelle: SLO → Alert-Rule vorhanden: ja/nein}

## Resilience-Patterns
{Circuit Breaker: ✅/❌ | Retry-Logic: ✅/❌ | Timeouts: ✅/❌}

## Alerting-Eskalation
{critical/warning/info-Routen: ✅/❌}

## Fehlende Monitoring-Konfigurationen
{Nummerierte Liste der Luecken}

## Bewertung
- ✅ NFR-007-konform / ❌ {N} Luecken identifiziert

Hinweis

Falls kein Monitoring-Setup gefunden wird, erstelle eine Liste der minimal erforderlichen Konfigurationen als Implementierungs-Checkliste.