La date from du schéma n'est pas la date d'installation — un 500 emportait les lignes fraîches

C'est le défaut le plus coûteux de ce lot, et celui qui ressemblait le moins à
ce qu'il était.

SYMPTÔME : `kubectl logs` montrait 19 lignes du pod témoin, Loki en montrait 0.
L'agent se déclarait sain, ses six composants `healthy`, 74 fichiers activement
suivis, le journal disait « start tailing file » sur le bon chemin, et TOUS ses
compteurs `loki_write_dropped_entries_total` valaient zéro — quelle que soit la
raison (ingester_error, line_too_long, queue_is_full, rate_limited,
stream_limited). Seul `loki_write_sent_entries_total = 0` disait qu'il ne
passait rien, sans dire pourquoi.

CAUSE, lisible uniquement dans le journal de Loki :

  POST /loki/api/v1/push (500)
    failed to create stream: no schema config found for time 1786622254.804
  entry ... has timestamp too old: 2026-04-13T13:17:53Z

`schemaConfig.configs[0].from` était posé à la date du jour. Or `from` dit
« à partir de quand ce schéma s'applique », PAS « depuis quand on garde ».
Sous cette date, Loki n'a aucun schéma pour les horodatages antérieurs.

Et l'agent lit aussi les fichiers ROTATÉS encore sur le disque (4.log, 9.log,
10.log…), qui portent des lignes vieilles de plusieurs mois — l'une de
2026-04-13. ⚠ Une poussée étant un LOT, le 500 emporte les lignes FRAÎCHES qui
voyageaient avec les vieilles. D'où : rien n'arrive, et rien ne l'explique côté
agent.

La date passe à 2020-01-01, antérieure à tout ce que ces machines peuvent
porter. Ce qui borne la conservation reste `retention_period` (720 h) et le
compacteur, pas le schéma.

⚠ À NOTER, PARCE QUE C'EST L'ISSUE #38 EN ABYME : cette cause n'était lisible
que dans le journal du pod Loki — qu'on ne pouvait lire que parce qu'il n'avait
pas redémarré. Le défaut qui empêchait de garder les journaux ne se
diagnostiquait que par un journal non gardé.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Fable 5.1 <[email protected]>

loki/values.yaml

@@ -52,9 +52,36 @@ loki:
 
     # ⚠ Le chart n'écrit AUCUN schéma par défaut (`schemaConfig: {}`) et refuse
     # de démarrer sans. tsdb + v13 est le couple courant de Loki 3.x.
+    #
+    # ⚠⚠ ET LA DATE `from` NE SE MET PAS AU JOUR DE L'INSTALLATION.
+    # C'est la faute qu'a faite le premier jet, et elle a coûté cher à
+    # diagnostiquer parce qu'elle ne ressemble à rien de ce qu'elle est.
+    #
+    # `from` dit « à partir de quand ce schéma s'applique », pas « depuis quand
+    # on garde ». Posée à la date du jour, Loki n'a AUCUN schéma pour les
+    # horodatages antérieurs et refuse la requête d'écriture ENTIÈRE :
+    #
+    #   POST /loki/api/v1/push (500)
+    #     failed to create stream: no schema config found for time 1786622254
+    #
+    # Or l'agent lit aussi les fichiers ROTATÉS encore présents sur le disque
+    # (4.log, 9.log, 10.log…), qui contiennent des lignes vieilles de plusieurs
+    # mois — une remontait à 2026-04-13. ⚠ Et comme une poussée est un LOT, le
+    # 500 emporte les lignes FRAÎCHES qui voyageaient avec les vieilles.
+    #
+    # Symptôme observé : `kubectl logs` montrait 19 lignes du pod témoin, Loki
+    # en montrait 0, l'agent se déclarait sain, ses compteurs `dropped` étaient
+    # tous à zéro — et `loki_write_sent_entries_total` valait 0. Rien ne
+    # DÉSIGNAIT la cause côté agent : elle n'était lisible que dans le journal
+    # de Loki. (Journal qu'on ne pouvait lire que parce que le pod n'avait pas
+    # redémarré. L'ironie est le sujet même de l'issue #38.)
+    #
+    # La date est donc largement antérieure à tout ce que le cluster peut
+    # porter. Ce qui borne la conservation, c'est `retention_period` +
+    # le compacteur, pas ceci.
     schemaConfig:
       configs:
-        - from: "2026-09-07"
+        - from: "2020-01-01"
           store: tsdb
           object_store: filesystem
           schema: v13