Les sondes de Loki cessent d'exiger une réponse en une seconde d'un Raspberry Pi

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]>

loki/values.yaml

@@ -26,6 +26,51 @@ loki:
   deploymentMode: SingleBinary
 
   loki:
+    # ── LES SONDES, RÉGLÉES POUR UN RASPBERRY PI (tools#44) ──────────────────
+    #
+    # ⚠⚠ 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`) sur un nœud
+    # tendu. Le défaut amont est `timeoutSeconds: 1` : **une seconde** pour
+    # répondre, ce qui est raisonnable sur une machine rapide et intenable ici.
+    #
+    # Conséquence, et elle n'est pas cosmétique : sans sonde verte, **aucun
+    # endpoint derrière le service**, donc la source de données Grafana est
+    # inutilisable — un magasin de journaux vivant mais injoignable.
+    #
+    # ⚠ LE REMÈDE N'EST PAS D'ASSOUPLIR LA DISPONIBILITÉ. On sépare deux
+    # questions que le défaut amont confondait :
+    #   · « Loki a-t-il fini de DÉMARRER ? » → `startupProbe`, patiente et
+    #     généreuse (jusqu'à 10 min : c'est le rejeu du WAL qu'on attend).
+    #   · « Loki répond-il MAL ? » → `readinessProbe`, qui reste stricte et
+    #     ne prend le relais qu'une fois le démarrage acquis.
+    # Un délai de 5 s y remplace la seconde amont : c'est le temps qu'un Pi
+    # chargé met à servir `/ready`, pas une tolérance à la panne.
+    startupProbe:
+      httpGet:
+        path: /ready
+        port: http-metrics
+      periodSeconds: 10
+      failureThreshold: 60 # 10 min pour rejouer un WAL, puis on abandonne
+      timeoutSeconds: 5
+    readinessProbe:
+      httpGet:
+        path: /ready
+        port: http-metrics
+      periodSeconds: 10
+      successThreshold: 1
+      failureThreshold: 3
+      timeoutSeconds: 5
+      # ⚠ `initialDelaySeconds: 0` est ÉCRIT, pas omis. Le chart FUSIONNE cette
+      # table avec la sienne au lieu de la remplacer : l'omettre laissait
+      # passer le `15` amont — vérifié au `helm template`, qui rendait encore
+      # `initialDelaySeconds: 15` sur un premier jet où je croyais l'avoir
+      # retiré. C'est le `startupProbe` qui tient la phase de démarrage ;
+      # attendre en plus ici ferait patienter deux fois et masquerait laquelle
+      # des deux sondes a réellement gardé quoi.
+      initialDelaySeconds: 0
+
     # Locataire unique : personne d'autre que le homelab n'écrit ici. Laisser
     # `true` obligerait chaque requête (et chaque source de données Grafana) à
     # porter un en-tête X-Scope-OrgID, pour aucun bénéfice.