From 698920ec8d60901a0017ad20b879c819c21ada65 Mon Sep 17 00:00:00 2001 From: Gabriel Radureau Date: Mon, 7 Sep 2026 17:45:19 +0200 Subject: [PATCH] =?UTF-8?q?`reject=5Fold=5Fsamples=5Fmax=5Fage`=20n'est=20?= =?UTF-8?q?pas=20la=20r=C3=A9tention=20=E2=80=94=20un=20lot=20refus=C3=A9?= =?UTF-8?q?=20bloque=20la=20file=20derri=C3=A8re=20lui?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Second blocage complet, découvert juste après celui du schéma et de la même famille : un réglage lu comme « combien de temps on garde » alors qu'il dit « quelles horloges on accepte ». Posé à 720 h pour « coller » à la rétention, il refusait chaque lot contenant une ligne de plus de 30 jours : entry ... has timestamp too old: 2026-04-13T13:47:05Z, oldest acceptable timestamp is: 2026-08-08T15:41:50Z Or l'agent lit les fichiers rotatés encore présents sur le disque, dont certains remontent à AVRIL. Et comme un lot définitivement refusé est REJOUÉ, la file ne se vide jamais : mesuré sur l'agent de pi3, `loki_write_sent_entries_total` valait 0 — il n'avait JAMAIS rien transmis, pour 74 fichiers activement suivis. Ce garde-fou existe contre les horloges décalées. On l'ouvre à 8760 h, bien au-delà de ce que le disque peut porter. Ce qui borne la conservation reste `retention_period` (720 h) plus le compacteur. ⚠ Conséquence assumée, écrite dans les valeurs : au premier démarrage l'agent remonte l'historique du disque, et le compacteur supprime ensuite ce qui dépasse 30 jours. On paie une ingestion inutile UNE fois, contre une file qui se vide — et on récupère au passage l'histoire déjà écrite. ⚠ Un état bloqué ne se débloque pas tout seul : après avoir corrigé Loki, il a fallu REDÉMARRER les agents. Le compteur d'un agent resté sur son ancien lot ne repart pas parce que le serveur, lui, va mieux. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Fable 5.1 --- loki/values.yaml | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/loki/values.yaml b/loki/values.yaml index eb64d2d..5e1405b 100644 --- a/loki/values.yaml +++ b/loki/values.yaml @@ -102,10 +102,32 @@ loki: limits_config: # -- 30 jours. Voir `RETENTION` en fin de fichier pour la mesure. retention_period: 720h - # Le défaut amont refuse tout échantillon de plus de 168 h. À la première - # remontée d'un agent resté hors ligne, ces lignes seraient jetées. + # ⚠⚠ CE N'EST PAS UN RÉGLAGE DE CONSERVATION, ET LE CONFONDRE BLOQUE TOUT. + # + # Posé à 720 h pour « coller » à la rétention, il a produit un second + # blocage complet, juste après celui du schéma : l'agent lit aussi les + # fichiers rotatés présents sur le disque, dont certains remontent à + # AVRIL. Loki refusait alors chaque lot — + # + # entry ... has timestamp too old: 2026-04-13T13:47:05Z, + # oldest acceptable timestamp is: 2026-08-08T15:41:50Z + # + # — et comme l'agent REJOUE un lot refusé, la file ne se vidait jamais : + # `loki_write_sent_entries_total` restait à 0 pour toujours. Un lot + # définitivement refusé bloque la file derrière lui. + # + # Ce garde-fou existe contre les horloges DÉCALÉES, pas pour borner la + # conservation. On l'ouvre donc largement au-delà de ce que le disque + # peut porter ; ce qui borne vraiment, c'est `retention_period` + le + # compacteur, plus bas. + # + # ⚠ Conséquence assumée : au tout premier démarrage, l'agent remonte + # l'historique encore sur le disque, et le compacteur supprimera dans + # l'heure ce qui dépasse 30 jours. On paie une ingestion inutile UNE + # fois, en échange d'une file qui se vide. Le bénéfice de bord est + # qu'on récupère au passage l'histoire déjà écrite. reject_old_samples: true - reject_old_samples_max_age: 720h + reject_old_samples_max_age: 8760h max_cache_freshness_per_query: 10m split_queries_by_interval: 15m query_timeout: 300s