Health Checks & Metriken
Diese Seite liefert Ihrem Betriebsteam konkrete Prüfungen und die wichtigsten zu beobachtenden Metriken. Sie ergänzt die Übersicht über den Stack unter Monitoring & Observability.
Täglicher Health Check (5 Minuten)
Führen Sie diese Befehle aus, um zu bestätigen, dass die Plattform fehlerfrei läuft:
# 1. Alle DuoKey-Pods Running/Ready und über Knoten verteilt
oc get pods -n duokey -o wide
# 2. Cluster-Operatoren fehlerfrei
oc get clusteroperators | grep -vi "True.*False.*False"
# 3. Ingress-Route liefert TLS aus
oc get route -n duokey
curl -I https://cockpit.duokey.example.local
# 4. Secrets werden injiziert (kein Klartext auf der Festplatte)
oc get externalsecret -n duokey
# 5. GitOps synchron
argocd app get duokey | grep -E "Sync Status|Health Status"
# 6. PersistentVolume-Auslastung
oc get pvc -A
Externe / VM-Ebene:
# OpenBao: muss entsiegelt sein mit aktivem Raft-Leader
bao status
# PostgreSQL: Primary aktiv, Replikate streamen, geringer Lag
oc exec -n duokey <pg-primary-pod> -- psql -c "SELECT client_addr, state, replay_lag FROM pg_stat_replication;"
Wichtige Metriken (SLIs)
Dies sind die Signale, die am wichtigsten sind. Erstellen Sie darauf basierende Grafana-Panels und Warnungen.
Anwendung
| Metrik | Warum sie wichtig ist | Gesunder Bereich |
|---|---|---|
| Anfragerate (Anf./s) | Last / Kapazität | Baseline-abhängig |
| Fehlerrate (5xx %) | Zuverlässigkeit | < 1 % |
| P95- / P99-Latenz | Benutzererfahrung | Innerhalb Ihres SLO |
| Aktive Sitzungen | Nutzung | Baseline-abhängig |
Secret-Engine (OpenBao / Vault)
| Metrik | Gesund |
|---|---|
| Siegelstatus | Entsiegelt bei Quorum |
| Raft-Leader vorhanden | Genau ein Leader |
| Anfragelatenz | Stabil, niedrig |
PostgreSQL
| Metrik | Gesund |
|---|---|
| Replikations-Lag | < 30 s |
| Aktive Verbindungen | Unterhalb von max_connections |
| Festplattenauslastung | < 85 % |
| Verfügbarkeit des Primary | Immer ein schreibbarer Primary |
Plattform
| Metrik | Gesund |
|---|---|
| Knoten-CPU / -Arbeitsspeicher | Reserve wird gehalten |
| Pod-Neustarts | Keine Crash-Loops |
| PV-Kapazität | < 85 % ausgelastet |
| etcd-Zustand | Alle Mitglieder fehlerfrei |
Vorgeschlagene SLOs
| Service-Level-Ziel | Zielwert |
|---|---|
| API-Verfügbarkeit | ≥ 99,9 % monatlich |
| API-P95-Latenz | ≤ Ihr vereinbarter Schwellenwert |
| Erfolgreiche Backups | 100 % der geplanten Durchläufe |
| RTO (Notfallwiederherstellung) | Siehe Backup & DR |
| RPO (Datenverlustfenster) | Siehe Backup & DR |
Synthetische / Liveness-Prüfungen
- Kubernetes-Liveness- und Readiness-Prüfungen sind auf jedem DuoKey-Pod konfiguriert, sodass OpenShift fehlerhafte Instanzen automatisch neu startet oder entfernt.
- Fügen Sie eine externe synthetische Prüfung (von Ihrem Monitoring-System oder LB-Health-Monitor) gegen die Cockpit-URL hinzu, um durchgängige Fehler zu erkennen.
Warnungen
Der empfohlene Satz an Warnungen ist dokumentiert unter Monitoring & Observability → Empfohlene Warnungen. Leiten Sie Warnungen an Ihren Bereitschaftskanal weiter (Alertmanager → E-Mail / Slack / PagerDuty / OpsGenie) und an Ihr SIEM zur Korrelation.