Recherche de toute brique de collecte de journaux dans le cluster (kubectl get pods -A, puis les namespaces) :
brique cherchée
présente ?
Loki
❌
OpenSearch / Elasticsearch
❌
Fluent Bit / Fluentd
❌
Vector
❌
Promtail
❌
Graylog
❌
Aucun namespace dédié non plus. La seule façon de lire un journal est kubectl logs, c'est-à-dire :
le tampon du kubelet, qui tourne — sur prometheus-server, l'historique disponible commençait à 02:06 alors que le pod avait 11 jours ;
et rien du tout après un redémarrage : ce qu'un pod a dit avant de mourir meurt avec lui.
Pourquoi ça vient de coûter cher
Deux fois cette semaine, sur le même sujet :
La mise à l'abri des vidéos échouait depuis des semaines (kadans#1033) et le journal du pod kadans-api était muet — le handler avalait l'erreur S3 derrière « stockage injoignable ». Corrigé depuis (kadans-api#218 journalise le code S3), mais cette ligne n'ira nulle part : elle vivra dans le tampon du kubelet jusqu'au prochain redémarrage.
Prometheus n'enregistrait plus depuis trois jours (#36). Ce qui a permis de dater la panne à la minute est le journal du pod — qui avait survécu par chance, parce qu'il n'avait pas redémarré depuis 11 jours. Un seul redémarrage et la date de début aurait été inconnue.
Autrement dit : on vient d'ajouter de bons messages de journal à l'endroit exact où ils comptent, dans un cluster qui ne les garde pas.
Le choix à faire, qui appartient au fondateur
Le fondateur nomme OpenSearch dans la pile visée. C'est le choix le plus riche et le plus coûteux ; sur trois Raspberry Pi, ce n'est pas neutre. L'arbitrage porte sur :
OpenSearch (+ Dashboards)
Loki (+ Grafana)
recherche plein texte
forte
par étiquettes, plein texte plus limité
coût mémoire / disque
élevé (JVM, index inversé)
faible (index par étiquettes seulement)
interface
Dashboards, à déployer en plus
Grafana est déjà là
indexation
tout le contenu
les étiquettes seulement
⚠ Je n'ai mesuré ni l'un ni l'autre sur ce matériel. Le nœud pi1 annonce 156 Go libres sur 491 Go côté Longhorn, mais je n'ai pas mesuré la mémoire disponible ni ce qu'une JVM y coûterait — c'est la mesure à faire avant de trancher, pas après.
La propriété à garder, quelle que soit la brique
Formulée pour être sabotable : un message écrit par un pod reste lisible après le redémarrage de ce pod. Le sabotage est direct — écrire une ligne reconnaissable, supprimer le pod, la rechercher. Sans cette démonstration, on aura déployé une pile de journaux qui rassure sans rien garder, et c'est exactement le défaut que #36 raconte.
⚠ Deuxième propriété, moins évidente et tout aussi importante : la collecte ne doit pas faire tomber ce qu'elle observe. Un agent qui lit tous les journaux de tous les pods sur un Raspberry Pi peut coûter plus que ce qu'il rapporte. Le plafond de ressources se pose au déploiement, pas après le premier incident.
## Mesuré le 2026-09-07
Recherche de toute brique de collecte de journaux dans le cluster (`kubectl get pods -A`, puis les namespaces) :
| brique cherchée | présente ? |
|---|---|
| Loki | ❌ |
| OpenSearch / Elasticsearch | ❌ |
| Fluent Bit / Fluentd | ❌ |
| Vector | ❌ |
| Promtail | ❌ |
| Graylog | ❌ |
**Aucun namespace** dédié non plus. La seule façon de lire un journal est `kubectl logs`, c'est-à-dire :
- **le tampon du kubelet**, qui tourne — sur `prometheus-server`, l'historique disponible commençait à 02:06 alors que le pod avait **11 jours** ;
- **et rien du tout après un redémarrage** : ce qu'un pod a dit avant de mourir meurt avec lui.
## Pourquoi ça vient de coûter cher
Deux fois cette semaine, sur le même sujet :
1. **La mise à l'abri des vidéos échouait depuis des semaines** ([kadans#1033](https://gitea.arcodange.lab/arcodange/kadans/issues/1033)) et le journal du pod `kadans-api` était **muet** — le handler avalait l'erreur S3 derrière « stockage injoignable ». Corrigé depuis (kadans-api#218 journalise le code S3), **mais cette ligne n'ira nulle part** : elle vivra dans le tampon du kubelet jusqu'au prochain redémarrage.
2. **Prometheus n'enregistrait plus depuis trois jours** ([#36](https://gitea.arcodange.lab/arcodange-org/tools/issues/36)). Ce qui a permis de dater la panne à la minute est le journal du pod — **qui avait survécu par chance**, parce qu'il n'avait pas redémarré depuis 11 jours. Un seul redémarrage et la date de début aurait été inconnue.
Autrement dit : on vient d'ajouter de bons messages de journal à l'endroit exact où ils comptent, dans un cluster qui **ne les garde pas**.
## Le choix à faire, qui appartient au fondateur
Le fondateur nomme **OpenSearch** dans la pile visée. C'est le choix le plus riche et le plus coûteux ; sur trois Raspberry Pi, ce n'est pas neutre. L'arbitrage porte sur :
| | OpenSearch (+ Dashboards) | Loki (+ Grafana) |
|---|---|---|
| recherche plein texte | forte | par étiquettes, plein texte plus limité |
| coût mémoire / disque | **élevé** (JVM, index inversé) | faible (index par étiquettes seulement) |
| interface | Dashboards, à déployer en plus | **Grafana est déjà là** |
| indexation | tout le contenu | les étiquettes seulement |
⚠ **Je n'ai mesuré ni l'un ni l'autre sur ce matériel.** Le nœud pi1 annonce 156 Go libres sur 491 Go côté Longhorn, mais je n'ai pas mesuré la mémoire disponible ni ce qu'une JVM y coûterait — c'est la mesure à faire avant de trancher, pas après.
## La propriété à garder, quelle que soit la brique
Formulée pour être sabotable : **un message écrit par un pod reste lisible après le redémarrage de ce pod.** Le sabotage est direct — écrire une ligne reconnaissable, supprimer le pod, la rechercher. Sans cette démonstration, on aura déployé une pile de journaux qui rassure sans rien garder, et c'est exactement le défaut que [#36](https://gitea.arcodange.lab/arcodange-org/tools/issues/36) raconte.
⚠ Deuxième propriété, moins évidente et tout aussi importante : **la collecte ne doit pas faire tomber ce qu'elle observe.** Un agent qui lit tous les journaux de tous les pods sur un Raspberry Pi peut coûter plus que ce qu'il rapporte. Le plafond de ressources se pose au déploiement, pas après le premier incident.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
⚠ Précision, parce que la prémisse mérite d'être corrigée : Loki n'est pas en place. La mesure de ce matin tient toujours — zéro pod de collecte, aucun namespace. Ce qui est déjà là, c'est Grafana, et c'est justement ce qui rend Loki le moins cher des deux : l'interface existe, il n'y a que le collecteur et le magasin à poser.
L'intention est claire et l'arbitrage est le bon. On part sur Loki.
Et une mesure qui renforce le choix, prise en le lançant
kubectl top nodes ce matin :
nœud
CPU
mémoire
pi1
15 %
77 %
pi2
59 %
106 %
pi3
31 %
64 %
pi2 est en surengagement mémoire. Une JVM OpenSearch sur ce cluster n'était pas seulement chère, elle était imprudente. Et ça pose une contrainte ferme pour Loki aussi : l'agent de collecte tourne sur chaque nœud par nature, donc les limites de ressources ne sont pas optionnelles, et l'empreinte réelle devra être mesurée après déploiement — pas supposée.
Ce qui est lancé
Le chantier est en cours dans une branche dédiée. Les deux propriétés à tenir, formulées pour être sabotables :
Un message écrit par un pod reste lisible après le redémarrage de ce pod. C'est la seule chose qui compte ; le reste est décoration.
La collecte ne fait pas tomber ce qu'elle observe — empreinte mesurée sur les trois nœuds, avant et après.
Restent à arbitrer sur mesure, pas au jugé : l'agent de collecte (⚠ Promtail est en fin de vie chez Grafana au profit d'Alloy — le choix se fera sur le coût mémoire réel en ARM64) et la rétention, qui sera calée sur le débit de journaux réellement mesuré du cluster.
## Arbitrage du fondateur (2026-09-07) : **Loki**
> « si Loki est déjà en place restons sur Loki. »
⚠ **Précision, parce que la prémisse mérite d'être corrigée** : Loki n'est **pas** en place. La mesure de ce matin tient toujours — zéro pod de collecte, aucun namespace. Ce qui est déjà là, c'est **Grafana**, et c'est justement ce qui rend Loki le moins cher des deux : l'interface existe, il n'y a que le collecteur et le magasin à poser.
L'intention est claire et l'arbitrage est le bon. **On part sur Loki.**
## Et une mesure qui renforce le choix, prise en le lançant
`kubectl top nodes` ce matin :
| nœud | CPU | **mémoire** |
|---|---|---|
| pi1 | 15 % | **77 %** |
| pi2 | 59 % | **106 %** |
| pi3 | 31 % | **64 %** |
**pi2 est en surengagement mémoire.** Une JVM OpenSearch sur ce cluster n'était pas seulement chère, elle était imprudente. Et ça pose une contrainte ferme pour Loki aussi : l'agent de collecte tourne sur **chaque** nœud par nature, donc les limites de ressources ne sont pas optionnelles, et l'empreinte réelle devra être mesurée après déploiement — pas supposée.
## Ce qui est lancé
Le chantier est en cours dans une branche dédiée. Les deux propriétés à tenir, formulées pour être sabotables :
1. **Un message écrit par un pod reste lisible après le redémarrage de ce pod.** C'est la seule chose qui compte ; le reste est décoration.
2. **La collecte ne fait pas tomber ce qu'elle observe** — empreinte mesurée sur les trois nœuds, avant et après.
Restent à arbitrer sur mesure, pas au jugé : l'agent de collecte (⚠ Promtail est en fin de vie chez Grafana au profit d'**Alloy** — le choix se fera sur le coût mémoire réel en ARM64) et la **rétention**, qui sera calée sur le débit de journaux réellement mesuré du cluster.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Mesuré le 2026-09-07
Recherche de toute brique de collecte de journaux dans le cluster (
kubectl get pods -A, puis les namespaces) :Aucun namespace dédié non plus. La seule façon de lire un journal est
kubectl logs, c'est-à-dire :prometheus-server, l'historique disponible commençait à 02:06 alors que le pod avait 11 jours ;Pourquoi ça vient de coûter cher
Deux fois cette semaine, sur le même sujet :
kadans-apiétait muet — le handler avalait l'erreur S3 derrière « stockage injoignable ». Corrigé depuis (kadans-api#218 journalise le code S3), mais cette ligne n'ira nulle part : elle vivra dans le tampon du kubelet jusqu'au prochain redémarrage.Autrement dit : on vient d'ajouter de bons messages de journal à l'endroit exact où ils comptent, dans un cluster qui ne les garde pas.
Le choix à faire, qui appartient au fondateur
Le fondateur nomme OpenSearch dans la pile visée. C'est le choix le plus riche et le plus coûteux ; sur trois Raspberry Pi, ce n'est pas neutre. L'arbitrage porte sur :
⚠ Je n'ai mesuré ni l'un ni l'autre sur ce matériel. Le nœud pi1 annonce 156 Go libres sur 491 Go côté Longhorn, mais je n'ai pas mesuré la mémoire disponible ni ce qu'une JVM y coûterait — c'est la mesure à faire avant de trancher, pas après.
La propriété à garder, quelle que soit la brique
Formulée pour être sabotable : un message écrit par un pod reste lisible après le redémarrage de ce pod. Le sabotage est direct — écrire une ligne reconnaissable, supprimer le pod, la rechercher. Sans cette démonstration, on aura déployé une pile de journaux qui rassure sans rien garder, et c'est exactement le défaut que #36 raconte.
⚠ Deuxième propriété, moins évidente et tout aussi importante : la collecte ne doit pas faire tomber ce qu'elle observe. Un agent qui lit tous les journaux de tous les pods sur un Raspberry Pi peut coûter plus que ce qu'il rapporte. Le plafond de ressources se pose au déploiement, pas après le premier incident.
🤖 Generated with Claude Code
Arbitrage du fondateur (2026-09-07) : Loki
⚠ Précision, parce que la prémisse mérite d'être corrigée : Loki n'est pas en place. La mesure de ce matin tient toujours — zéro pod de collecte, aucun namespace. Ce qui est déjà là, c'est Grafana, et c'est justement ce qui rend Loki le moins cher des deux : l'interface existe, il n'y a que le collecteur et le magasin à poser.
L'intention est claire et l'arbitrage est le bon. On part sur Loki.
Et une mesure qui renforce le choix, prise en le lançant
kubectl top nodesce matin :pi2 est en surengagement mémoire. Une JVM OpenSearch sur ce cluster n'était pas seulement chère, elle était imprudente. Et ça pose une contrainte ferme pour Loki aussi : l'agent de collecte tourne sur chaque nœud par nature, donc les limites de ressources ne sont pas optionnelles, et l'empreinte réelle devra être mesurée après déploiement — pas supposée.
Ce qui est lancé
Le chantier est en cours dans une branche dédiée. Les deux propriétés à tenir, formulées pour être sabotables :
Restent à arbitrer sur mesure, pas au jugé : l'agent de collecte (⚠ Promtail est en fin de vie chez Grafana au profit d'Alloy — le choix se fera sur le coût mémoire réel en ARM64) et la rétention, qui sera calée sur le débit de journaux réellement mesuré du cluster.
🤖 Generated with Claude Code