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

Un startupProbe patient tient le rejeu du WAL, la readinessProbe reste stricte
ensuite. 30 échecs en 25 min sur un Loki parfaitement sain, faute d'une
seconde — et sans endpoint, la source de données Grafana était inutilisable.

Traite le point 2 de #44.

Co-Authored-By: Claude Opus 5 <[email protected]>
Co-authored-by: Gabriel Radureau <[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.