From 857a6d15608f3c40008cde0178edec5e0bab426b Mon Sep 17 00:00:00 2001 From: Gabriel Radureau Date: Mon, 7 Sep 2026 17:41:14 +0200 Subject: [PATCH] =?UTF-8?q?La=20date=20`from`=20du=20sch=C3=A9ma=20n'est?= =?UTF-8?q?=20pas=20la=20date=20d'installation=20=E2=80=94=20un=20500=20em?= =?UTF-8?q?portait=20les=20lignes=20fra=C3=AEches?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- loki/values.yaml | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/loki/values.yaml b/loki/values.yaml index 0f96b83..eb64d2d 100644 --- a/loki/values.yaml +++ b/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