fix(grafana): startupProbe pour les migrations SQLite (CrashLoop au rollout) #8

Merged
arcodange merged 1 commits from arcodange/grafana-startupprobe into main 2026-07-08 20:16:00 +02:00
Owner

Incident

Le rollout du dashboard prospection (#7) a déclenché un redémarrage de Grafana qui a révélé un problème latent : Grafana tourne en SQLite sur emptyDir (aucun PVC) → il rejoue toute la migration du schéma à chaque démarrage de pod, ce qui dépasse ~160 s sur Raspberry Pi. La livenessProbe (initialDelay 60 s + 10×10 s) tuait donc Grafana en pleine migration → le nouveau pod CrashLoop (RESTARTS qui grimpe, jamais Ready).

Pas de coupure : le Service ne route que vers le pod Ready, donc l'ancien pod a continué de servir. Mais le rollout restait bloqué et tout futur redémarrage aurait planté.

Fix

  • startupProbe (jusqu'à ~10 min) : la liveness n'est armée qu'après le démarrage → les migrations ont le temps d'aboutir.
  • livenessProbe.failureThreshold 10 → 60 : filet de sécurité si le chart n'expose pas startupProbe.

Fix pérenne possible (hors scope) : DB Grafana persistante (PVC) ou externe (postgres du lab) → plus de migration complète à chaque démarrage.

Validation

  • YAML OK (startupProbe.failureThreshold=60, livenessProbe.failureThreshold=60).
  • Après merge : sync ArgoCD → nouveau pod Grafana migre sans être tué → Ready → dashboard « Prospection » chargé.

🤖 Generated with Claude Code

## Incident Le rollout du dashboard prospection ([#7](https://gitea.arcodange.lab/arcodange-org/tools/pulls/7)) a déclenché un redémarrage de Grafana qui a **révélé un problème latent** : Grafana tourne en **SQLite sur `emptyDir`** (aucun PVC) → il rejoue **toute la migration du schéma à chaque démarrage de pod**, ce qui dépasse ~160 s sur Raspberry Pi. La `livenessProbe` (initialDelay 60 s + 10×10 s) tuait donc Grafana **en pleine migration** → le nouveau pod **CrashLoop** (RESTARTS qui grimpe, jamais `Ready`). Pas de coupure : le Service ne route que vers le pod *Ready*, donc l'ancien pod a continué de servir. Mais le rollout restait bloqué et tout futur redémarrage aurait planté. ## Fix - **`startupProbe`** (jusqu'à ~10 min) : la liveness n'est armée qu'après le démarrage → les migrations ont le temps d'aboutir. - **`livenessProbe.failureThreshold` 10 → 60** : filet de sécurité si le chart n'expose pas `startupProbe`. Fix pérenne possible (hors scope) : DB Grafana persistante (PVC) ou externe (postgres du lab) → plus de migration complète à chaque démarrage. ## Validation - YAML OK (`startupProbe.failureThreshold=60`, `livenessProbe.failureThreshold=60`). - Après merge : sync ArgoCD → nouveau pod Grafana migre sans être tué → `Ready` → dashboard « Prospection » chargé. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange added 1 commit 2026-07-08 20:15:26 +02:00
fix(grafana): startupProbe + liveness grace pour les migrations SQLite
Helm Charts / Detect changed charts (push) Successful in 24s
Helm Charts / Library charts tool (push) Has been skipped
Helm Charts / Application charts pgcat (push) Has been skipped
Helm Charts / Detect changed charts (pull_request) Successful in 17s
Helm Charts / Library charts tool (pull_request) Has been skipped
Helm Charts / Application charts pgcat (pull_request) Has been skipped
e419cb6307
Grafana tourne en SQLite sur emptyDir → migration complète du schéma à chaque
démarrage de pod, > 160 s sur Raspberry Pi. La liveson (initialDelay 60 + 10×10s)
tuait Grafana en pleine migration → CrashLoop du nouveau pod à chaque rollout
(révélé par le rollout du dashboard prospection). Ajoute une startupProbe (~10 min)
et relève failureThreshold de la liveness (filet si le chart n'expose pas startupProbe).

Co-Authored-By: Claude Opus 4.8 <[email protected]>
arcodange merged commit 1eabae6936 into main 2026-07-08 20:15:59 +02:00
arcodange deleted branch arcodange/grafana-startupprobe 2026-07-08 20:16:05 +02:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arcodange-org/tools#8