Le plafond de l'agent passe à 384 Mi — 256 laissait 84 % d'occupation sur pi1
Helm Charts / Detect changed charts (pull_request) Successful in 28s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts crowdsec (pull_request) Skipped
Helm Charts / Application charts hashicorp-vault (pull_request) Skipped
Helm Charts / Application charts minio (pull_request) Skipped
Helm Charts / Application charts pgbouncer (pull_request) Skipped
Helm Charts / Application charts pgcat (pull_request) Skipped
Helm Charts / Application charts prometheus (pull_request) Skipped
Helm Charts / Application charts redis (pull_request) Skipped
Helm Charts / Application charts loki (pull_request) Successful in 16s
Helm Charts / Application charts chart (pull_request) Successful in 36s
Helm Charts / Application charts alloy (pull_request) Successful in 51s
Helm Charts / Application charts grafana (pull_request) Successful in 55s

Relevé sur la pile qui tourne (`kubectl top pods --containers`), pendant la
reprise de l'historique :

  agent de pi1   214 Mi   ← 84 % du plafond de 256 Mi
  agent de pi2    98 Mi
  agent de pi3    83 Mi

Aucun OOMKill constaté (0 redémarrage sur les trois), mais 84 % n'est pas une
marge. Un agent tué perd sa position de lecture, et un trou dans la collecte
est exactement ce que ce lot existe pour supprimer.

⚠ Relever un PLAFOND ne consomme rien : il borne le pire cas. C'est la REQUÊTE
(128 Mi, inchangée) que le planificateur réserve — donc rien n'est retiré à
pi2, le nœud tendu.

⚠ L'écart entre les trois nœuds n'est pas du bruit : il suit le nombre de
fichiers suivis, donc le nombre de conteneurs du nœud.

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

Co-Authored-By: Claude Fable 5.1 <[email protected]>
This commit is contained in:
2026-09-07 17:51:01 +02:00
co-authored by Claude Fable 5.1
parent 698920ec8d
commit bb14dc38d5
+20 -1
View File
@@ -98,7 +98,26 @@ alloy:
limits:
# Pas de limite CPU (l'étranglement d'un agent lui fait perdre des
# lignes en silence, ce qui est le défaut qu'on essaie de supprimer).
memory: 256Mi
#
# ⚠ 384 Mi, ET C'EST UN CHIFFRE MESURÉ, PAS UN CHIFFRE ROND.
# Le premier jet plafonnait à 256 Mi. Relevé sur la pile qui tourne,
# pendant la reprise de l'historique (`kubectl top pods --containers`) :
#
# agent de pi1 214 Mi ← 84 % du plafond de 256 Mi
# agent de pi2 98 Mi
# agent de pi3 83 Mi
#
# Aucun OOMKill constaté (0 redémarrage sur les trois), mais 84 % n'est
# pas une marge : un agent tué perd sa position de lecture, et un trou
# dans la collecte est exactement ce que ce lot existe pour supprimer.
#
# ⚠ Relever un PLAFOND ne consomme rien : il borne le pire cas. C'est la
# REQUÊTE (128 Mi, inchangée) que le planificateur réserve.
#
# ⚠ L'écart entre les trois nœuds n'est pas du bruit : il suit le nombre
# de fichiers suivis, donc le nombre de conteneurs du nœud. Un nœud qui
# se remplit fera monter son agent.
memory: 384Mi
# Pas de grappe : chaque agent lit SON nœud, il n'a rien à coordonner.
clustering: