Version : 1.0 — 28/07/2026
Public : Support N2
Stack : kube-prometheus-stack (release kps), Alertmanager → Telegram (critique) + devops@rber.bj (warning), Grafana
Chaque alerte reçue suit le même cycle : accuser réception (Telegram) → ouvrir ticket Zammad → diagnostiquer selon la table §3 → agir ou escalader → clôturer avec cause consignée. Une alerte qui « disparaît toute seule » sans cause identifiée reste un ticket ouvert.
Pods de la stack :
kubectl -n RENSEIGNER_NS_MONITORING get pods
# alertmanager-kps-alertmanager-0, prometheus-kps-prometheus-0, kps-grafana-*
Avant de conclure « pas d'alerte = pas de problème » :
| Alerte | Gravité | Diagnostic | Action N2 | Escalade N3 si |
|---|---|---|---|---|
KubePodCrashLooping > 15 min |
Critique | kubectl -n <ns> describe pod + logs --previous. Identifier : OOM ? dépendance down (base, DNS) ? volume ? |
Si cause = dépendance : traiter la dépendance (runbook du service). Si OOM : consigner, ne pas augmenter les limits sans validation | Cause non identifiée en 30 min ; workload stateful |
| Cluster CNPG non healthy > 1 h | Critique | kubectl -n <ns> get clusters.postgresql.cnpg.io — quelle instance manque, depuis quand |
Réplique en reconstruction : surveiller. Bloquée > 1 h : vérifier NetworkPolicies egress (DNS + intra-namespace + MinIO) | Primaire down ; reconstruction bloquée après vérif NetPol |
| Sauvegarde CNPG en échec ou absente > 24 h | Critique | kubectl -n <ns> get backups.postgresql.cnpg.io --sort-by=.metadata.creationTimestamp |
Runbook-N2-Sauvegardes §3. Précédent : backstage 18 jours d'échec silencieux | Échec persistant après 1 relance |
| Service LoadBalancer sans endpoint | Critique | kubectl -n <ns> get endpoints ; annonce L2 MetalLB |
Runbook-N2-Mail §5 (même logique pour tout service LB) | Modification MetalLB nécessaire |
KubeNodeNotReady |
Critique | kubectl get nodes ; kubectl describe node ; la VM tourne-t-elle côté Harvester ? |
Ne pas redémarrer la VM sans N3. Collecter : quel nœud, quel hôte physique le porte | Toujours (action sur nœud = N3) |
| Volume Longhorn dégradé/faulted | Critique | UI Longhorn : combien de répliques saines ? | 1 réplique perdue : surveiller la reconstruction | faulted (0 réplique saine) → N3 immédiat, ne rien tenter |
| Certificat < 15 jours | Warning | Quel Ingress, quel secret TLS | Vérifier cert-manager : kubectl get certificates -A — renouvellement bloqué ? |
Renouvellement manuel requis |
| Espace disque nœud > 80 % | Warning | kubectl describe node ; côté Harvester : espace Longhorn hôte |
Identifier le consommateur (logs ? images ? volumes orphelins ?) | > 90 %, ou nettoyage requis sur l'hôte |
| PVC > 85 % | Warning | Quel service, croissance normale ? | Consigner. Attention : l'extension en ligne Longhorn est peu fiable sur cette installation pour les volumes RWO attachés — extension = opération planifiée N3 (détacher d'abord) | Extension nécessaire |
Cible Prometheus down (TargetDown) |
Warning | Quel exporter ? Le service lui-même est-il up ? | Si le service est up mais l'exporter down : redémarrer le pod exporter | Service down (→ runbook du service) |
| Alerte mémoire/CPU nœud | Warning | Grafana : quel pod consomme ? Depuis quand ? | Consigner tendance. Pas d'eviction manuelle | Saturation persistante (capacité = N3) |
Plus de 5 alertes critiques simultanées = suspicion incident infrastructure (précédent 23/07 : ~25 volumes faulted d'un coup).
10.29.112.130–133) → switch stockage ? → VMs RKE2 up ?# UI Alertmanager via port-forward
kubectl -n RENSEIGNER_NS_MONITORING port-forward svc/kps-alertmanager 9093:9093
Le plan d'action INC-RBER-2026-07-23 impose ces alertes. Vérifier leur présence ; toute alerte manquante = ticket vers N3 :
vmbackup) non Ready — RENSEIGNER_ (cross-cluster, chantier en cours)kubectl get pods -A | grep -v Running | grep -v Completed : pods anormaux non alertés ?vmbackup Harvester Ready