Le défaut, mesuré quelques heures après le déploiement
30 échecs de la sonde de disponibilité en 25 minutes, tous en context deadline exceeded — pendant que Loki tournait parfaitement. Il finissait de rejouer son WAL (checkpoint done time=4m23s) sur un nœud tendu.
Une seconde pour répondre. C'est le défaut amont, raisonnable sur une machine rapide, intenable sur un Pi qui rejoue un journal.
La conséquence n'était pas cosmétique : sans sonde verte, aucun endpoint derrière le service — donc la source de données Grafana inutilisable. Un magasin de journaux vivant mais injoignable.
Le remède n'assouplit pas la disponibilité, il sépare deux questions
Le défaut amont confondait « Loki a-t-il fini de démarrer ? » et « Loki répond-il mal ? ». Une seule sonde ne peut pas répondre aux deux sans se tromper d'au moins une.
startupProbe — patiente, jusqu'à 10 minutes. C'est le rejeu du WAL qu'on attend, et il a le droit d'être long.
readinessProbe — stricte, et elle ne prend le relais qu'une fois le démarrage acquis. Le délai passe de 1 s à 5 s, ce qui est le temps qu'un Pi chargé met à servir /ready — pas une tolérance à la panne.
⚠ Ce que le rendu m'a appris, et que je n'aurais pas deviné
Mon premier jet omettaitinitialDelaySeconds, en croyant le supprimer. helm template a rendu initialDelaySeconds: 15 quand même : le chart FUSIONNE cette table avec la sienne au lieu de la remplacer. Il est donc désormais écrit à 0, explicitement, avec sa raison.
C'est le rendu qui l'a dit, pas moi. Sans ce passage par helm template, le commentaire aurait affirmé le contraire de la réalité.
⚠ Le sabotage a mordu, mais ma vérification qu'il était APPLIQUÉ a imprimé un « False » trompeur : elle cherchait le mot startupProbe dans une zone qui contient un bloc de commentaires le mentionnant. C'est le rendu qui fait foi, pas ma sonde. Je le signale parce que sans le rendu j'aurais pu conclure que le sabotage n'avait pas été posé.
Ce que ça ne prouve pas
Le comportement sous charge réelle. Le rendu prouve la configuration produite, pas que le pod passera Ready du premier coup. Il faudra le constater au prochain redémarrage — et c'est la seule preuve qui comptera.
Restent les deux autres points de #44 : l'adoption de loki par ArgoCD (⚠ elle s'est faite d'elle-même depuis, les deux applications sont Synced/Healthy) et la saturation de pi2, dont la cause de fond — des requests presque nulle part déclarées sur ce cluster — dépasse ce chart.
Traite le point 2 de #44.
## Le défaut, mesuré quelques heures après le déploiement
**30 échecs de la sonde de disponibilité en 25 minutes**, tous en `context deadline exceeded` — pendant que Loki tournait parfaitement. Il finissait de rejouer son WAL (`checkpoint done time=4m23s`) sur un nœud tendu.
```
readinessProbe: { timeoutSeconds: 1, periodSeconds: 10, failureThreshold: 3 }
```
**Une seconde** pour répondre. C'est le défaut amont, raisonnable sur une machine rapide, intenable sur un Pi qui rejoue un journal.
La conséquence n'était pas cosmétique : sans sonde verte, **aucun endpoint derrière le service** — donc la source de données Grafana inutilisable. Un magasin de journaux vivant mais injoignable.
## Le remède n'assouplit pas la disponibilité, il sépare deux questions
Le défaut amont confondait « Loki a-t-il fini de **démarrer** ? » et « Loki répond-il **mal** ? ». Une seule sonde ne peut pas répondre aux deux sans se tromper d'au moins une.
- **`startupProbe`** — patiente, jusqu'à 10 minutes. C'est le rejeu du WAL qu'on attend, et il a le droit d'être long.
- **`readinessProbe`** — stricte, et elle ne prend le relais **qu'une fois le démarrage acquis**. Le délai passe de 1 s à 5 s, ce qui est le temps qu'un Pi chargé met à servir `/ready` — pas une tolérance à la panne.
## ⚠ Ce que le rendu m'a appris, et que je n'aurais pas deviné
Mon premier jet **omettait** `initialDelaySeconds`, en croyant le supprimer. `helm template` a rendu `initialDelaySeconds: 15` quand même : **le chart FUSIONNE cette table avec la sienne au lieu de la remplacer**. Il est donc désormais **écrit à 0**, explicitement, avec sa raison.
C'est le rendu qui l'a dit, pas moi. Sans ce passage par `helm template`, le commentaire aurait affirmé le contraire de la réalité.
## Éprouvé par rendu local, les deux côtés
| état | ce que le StatefulSet porte |
|---|---|
| **livré** | `startup={failureThreshold 60, timeout 5s}`, `readiness={timeout 5s, initialDelay 0}` |
| **`startupProbe` retiré** (sabotage) | `startup=(aucune)` — le sabotage mord |
⚠ **Le sabotage a mordu, mais ma vérification qu'il était APPLIQUÉ a imprimé un « False » trompeur** : elle cherchait le mot `startupProbe` dans une zone qui contient un bloc de commentaires le mentionnant. C'est le **rendu** qui fait foi, pas ma sonde. Je le signale parce que sans le rendu j'aurais pu conclure que le sabotage n'avait pas été posé.
## Ce que ça ne prouve pas
**Le comportement sous charge réelle.** Le rendu prouve la configuration produite, pas que le pod passera `Ready` du premier coup. Il faudra le constater au prochain redémarrage — et c'est la seule preuve qui comptera.
Restent les deux autres points de #44 : l'adoption de `loki` par ArgoCD (⚠ elle s'est faite d'elle-même depuis, les deux applications sont `Synced/Healthy`) et la saturation de pi2, dont la cause de fond — des `requests` presque nulle part déclarées sur ce cluster — dépasse ce chart.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Mesuré le 2026-09-07, quelques heures après le premier déploiement : 30 échecs
de la sonde de disponibilité en 25 minutes, tous en `context deadline
exceeded` — pendant que Loki tournait parfaitement. Il finissait de rejouer
son WAL (`checkpoint done time=4m23s`). Le défaut amont est
`timeoutSeconds: 1`, raisonnable sur une machine rapide et intenable ici.
La conséquence n'était pas cosmétique : sans sonde verte, aucun endpoint
derrière le service, donc la source de données Grafana inutilisable — un
magasin de journaux vivant mais injoignable.
Le remède n'assouplit PAS la disponibilité. Il sépare deux questions que le
défaut amont confondait : « Loki a-t-il fini de DÉMARRER ? » (`startupProbe`,
jusqu'à 10 min, c'est le rejeu du WAL qu'on attend) et « répond-il MAL ? »
(`readinessProbe`, stricte, qui ne prend le relais qu'ensuite).
⚠ `initialDelaySeconds: 0` est ÉCRIT, pas omis : le chart FUSIONNE cette table
avec la sienne au lieu de la remplacer. Un premier jet l'omettait, et
`helm template` rendait encore le `15` amont. Le rendu l'a dit, pas moi.
Éprouvé par rendu local, `helm template`, les deux côtés :
livré startup={failureThreshold 60, timeout 5s}
readiness={timeout 5s, initialDelay 0} ← conforme
startupProbe ôté startup=(aucune) ← le sabotage mord
⚠ Le sabotage a mordu, mais ma vérification qu'il était APPLIQUÉ a imprimé un
« False » trompeur (elle cherchait le mot dans un bloc de commentaires qui le
contient). C'est le RENDU qui fait foi, pas ma sonde.
⚠ Ce que ça ne prouve pas : le comportement sous charge réelle. Il faudra
constater que le pod passe `Ready` du premier coup au prochain redémarrage.
Traite un des trois restes de #44.
Co-Authored-By: Claude Opus 5 <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Traite le point 2 de #44.
Le défaut, mesuré quelques heures après le déploiement
30 échecs de la sonde de disponibilité en 25 minutes, tous en
context deadline exceeded— pendant que Loki tournait parfaitement. Il finissait de rejouer son WAL (checkpoint done time=4m23s) sur un nœud tendu.Une seconde pour répondre. C'est le défaut amont, raisonnable sur une machine rapide, intenable sur un Pi qui rejoue un journal.
La conséquence n'était pas cosmétique : sans sonde verte, aucun endpoint derrière le service — donc la source de données Grafana inutilisable. Un magasin de journaux vivant mais injoignable.
Le remède n'assouplit pas la disponibilité, il sépare deux questions
Le défaut amont confondait « Loki a-t-il fini de démarrer ? » et « Loki répond-il mal ? ». Une seule sonde ne peut pas répondre aux deux sans se tromper d'au moins une.
startupProbe— patiente, jusqu'à 10 minutes. C'est le rejeu du WAL qu'on attend, et il a le droit d'être long.readinessProbe— stricte, et elle ne prend le relais qu'une fois le démarrage acquis. Le délai passe de 1 s à 5 s, ce qui est le temps qu'un Pi chargé met à servir/ready— pas une tolérance à la panne.⚠ Ce que le rendu m'a appris, et que je n'aurais pas deviné
Mon premier jet omettait
initialDelaySeconds, en croyant le supprimer.helm templatea renduinitialDelaySeconds: 15quand même : le chart FUSIONNE cette table avec la sienne au lieu de la remplacer. Il est donc désormais écrit à 0, explicitement, avec sa raison.C'est le rendu qui l'a dit, pas moi. Sans ce passage par
helm template, le commentaire aurait affirmé le contraire de la réalité.Éprouvé par rendu local, les deux côtés
startup={failureThreshold 60, timeout 5s},readiness={timeout 5s, initialDelay 0}startupProberetiré (sabotage)startup=(aucune)— le sabotage mord⚠ Le sabotage a mordu, mais ma vérification qu'il était APPLIQUÉ a imprimé un « False » trompeur : elle cherchait le mot
startupProbedans une zone qui contient un bloc de commentaires le mentionnant. C'est le rendu qui fait foi, pas ma sonde. Je le signale parce que sans le rendu j'aurais pu conclure que le sabotage n'avait pas été posé.Ce que ça ne prouve pas
Le comportement sous charge réelle. Le rendu prouve la configuration produite, pas que le pod passera
Readydu premier coup. Il faudra le constater au prochain redémarrage — et c'est la seule preuve qui comptera.Restent les deux autres points de #44 : l'adoption de
lokipar ArgoCD (⚠ elle s'est faite d'elle-même depuis, les deux applications sontSynced/Healthy) et la saturation de pi2, dont la cause de fond — desrequestspresque nulle part déclarées sur ce cluster — dépasse ce chart.🤖 Generated with Claude Code
Mesuré le 2026-09-07, quelques heures après le premier déploiement : 30 échecs de la sonde de disponibilité en 25 minutes, tous en `context deadline exceeded` — pendant que Loki tournait parfaitement. Il finissait de rejouer son WAL (`checkpoint done time=4m23s`). Le défaut amont est `timeoutSeconds: 1`, raisonnable sur une machine rapide et intenable ici. La conséquence n'était pas cosmétique : sans sonde verte, aucun endpoint derrière le service, donc la source de données Grafana inutilisable — un magasin de journaux vivant mais injoignable. Le remède n'assouplit PAS la disponibilité. Il sépare deux questions que le défaut amont confondait : « Loki a-t-il fini de DÉMARRER ? » (`startupProbe`, jusqu'à 10 min, c'est le rejeu du WAL qu'on attend) et « répond-il MAL ? » (`readinessProbe`, stricte, qui ne prend le relais qu'ensuite). ⚠ `initialDelaySeconds: 0` est ÉCRIT, pas omis : le chart FUSIONNE cette table avec la sienne au lieu de la remplacer. Un premier jet l'omettait, et `helm template` rendait encore le `15` amont. Le rendu l'a dit, pas moi. Éprouvé par rendu local, `helm template`, les deux côtés : livré startup={failureThreshold 60, timeout 5s} readiness={timeout 5s, initialDelay 0} ← conforme startupProbe ôté startup=(aucune) ← le sabotage mord ⚠ Le sabotage a mordu, mais ma vérification qu'il était APPLIQUÉ a imprimé un « False » trompeur (elle cherchait le mot dans un bloc de commentaires qui le contient). C'est le RENDU qui fait foi, pas ma sonde. ⚠ Ce que ça ne prouve pas : le comportement sous charge réelle. Il faudra constater que le pod passe `Ready` du premier coup au prochain redémarrage. Traite un des trois restes de #44. Co-Authored-By: Claude Opus 5 <[email protected]>