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]>
2026-09-08 01:51:37 +02:00
parent 00d89981ac
commit 4e954a6890
1 changed files with 45 additions and 0 deletions
@@ -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.