Contrôles de santé et métriques
Cette page fournit à votre équipe d'exploitation des contrôles concrets ainsi que les métriques clés à surveiller. Elle complète l'aperçu de la pile Surveillance et observabilité.
Contrôle de santé quotidien (5 minutes)
Exécutez ces commandes pour confirmer que la plateforme est saine :
# 1. Tous les pods DuoKey sont Running/Ready et répartis sur les nœuds
oc get pods -n duokey -o wide
# 2. Opérateurs de cluster sains
oc get clusteroperators | grep -vi "True.*False.*False"
# 3. La route Ingress dessert TLS
oc get route -n duokey
curl -I https://cockpit.duokey.example.local
# 4. Secrets injectés (aucun texte en clair sur le disque)
oc get externalsecret -n duokey
# 5. GitOps synchronisé
argocd app get duokey | grep -E "Sync Status|Health Status"
# 6. Utilisation des PersistentVolume
oc get pvc -A
Niveau externe / VM :
# OpenBao : doit être déverrouillé avec un leader Raft actif
bao status
# PostgreSQL : primaire actif, réplicas en streaming, faible latence
oc exec -n duokey <pg-primary-pod> -- psql -c "SELECT client_addr, state, replay_lag FROM pg_stat_replication;"
Métriques clés (SLI)
Ce sont les signaux qui comptent le plus. Construisez des panneaux Grafana et des alertes sur cette base.
Application
| Métrique | Pourquoi c'est important | Plage saine |
|---|---|---|
| Débit de requêtes (req/s) | Charge / capacité | Dépend de la référence |
| Taux d'erreur (% 5xx) | Fiabilité | < 1 % |
| Latence P95 / P99 | Expérience utilisateur | Dans votre SLO |
| Sessions actives | Utilisation | Dépend de la référence |
Moteur de secrets (OpenBao / Vault)
| Métrique | Sain |
|---|---|
| État de scellement | Déverrouillé sur quorum |
| Présence d'un leader Raft | Exactement un leader |
| Latence des requêtes | Stable, faible |
PostgreSQL
| Métrique | Sain |
|---|---|
| Latence de réplication | < 30 s |
| Connexions actives | En dessous de max_connections |
| Utilisation du disque | < 85 % |
| Disponibilité du primaire | Toujours un primaire accessible en écriture |
Plateforme
| Métrique | Sain |
|---|---|
| CPU / mémoire des nœuds | Marge maintenue |
| Redémarrages de pods | Aucune boucle de crash |
| Capacité des PV | < 85 % utilisée |
| Santé etcd | Tous les membres sains |
SLO suggérés
| Objectif de niveau de service | Cible |
|---|---|
| Disponibilité de l'API | ≥ 99,9 % mensuel |
| Latence P95 de l'API | ≤ votre seuil convenu |
| Sauvegardes réussies | 100 % des exécutions planifiées |
| RTO (reprise après sinistre) | Voir Sauvegarde et reprise après sinistre |
| RPO (fenêtre de perte de données) | Voir Sauvegarde et reprise après sinistre |
Sondes synthétiques / de vivacité
- Des sondes de vivacité (liveness) et de disponibilité (readiness) Kubernetes sont configurées sur chaque pod DuoKey afin qu'OpenShift redémarre ou retire automatiquement les instances défaillantes.
- Ajoutez un contrôle synthétique externe (depuis votre système de surveillance ou le moniteur de santé du LB) sur l'URL du Cockpit pour détecter les défaillances de bout en bout.
Alertes
L'ensemble d'alertes recommandé est documenté dans Surveillance et observabilité → Alertes recommandées. Acheminez les alertes vers votre canal d'astreinte (Alertmanager → e-mail / Slack / PagerDuty / OpsGenie) et vers votre SIEM pour corrélation.