Ce qu'un pod a dit lui survit — Loki et Alloy, sous plafond (#38) #40
@@ -293,9 +293,9 @@ jobs:
|
||||
needs: [filter-chart,library-charts]
|
||||
strategy:
|
||||
matrix:
|
||||
# ⚠ Les NEUF charts applicatifs du dépôt — voir l'avertissement du job
|
||||
# ⚠ Les ONZE charts applicatifs du dépôt — voir l'avertissement du job
|
||||
# `library-charts` ci-dessus. Un chart absent de cette liste n'est
|
||||
# JAMAIS construit, et sa PR est verte quand même.
|
||||
# chart: ${{ fromJson(needs.filter-chart.outputs.application_charts) }}
|
||||
chart: [chart, crowdsec, grafana, hashicorp-vault, minio, pgbouncer, pgcat, prometheus, redis]
|
||||
chart: [alloy, chart, crowdsec, grafana, hashicorp-vault, loki, minio, pgbouncer, pgcat, prometheus, redis]
|
||||
type: [application]
|
||||
@@ -0,0 +1,23 @@
|
||||
# Patterns to ignore when building packages.
|
||||
# This supports shell glob matching, relative path matching, and
|
||||
# negation (prefixed with !). Only one pattern per line.
|
||||
.DS_Store
|
||||
# Common VCS dirs
|
||||
.git/
|
||||
.gitignore
|
||||
.bzr/
|
||||
.bzrignore
|
||||
.hg/
|
||||
.hgignore
|
||||
.svn/
|
||||
# Common backup files
|
||||
*.swp
|
||||
*.bak
|
||||
*.tmp
|
||||
*.orig
|
||||
*~
|
||||
# Various IDEs
|
||||
.project
|
||||
.idea/
|
||||
*.tmproj
|
||||
.vscode/
|
||||
@@ -0,0 +1,16 @@
|
||||
apiVersion: v2
|
||||
name: alloy
|
||||
description: >-
|
||||
L'agent qui ramasse les journaux de chaque nœud et les pousse vers Loki.
|
||||
Un DaemonSet — donc trois pods, un par Raspberry Pi.
|
||||
|
||||
# Même raison que pour `loki/` : aucune dépendance au registre Helm interne,
|
||||
# que le runner de CI ne résout pas (relevé du 2026-09-07). Voir loki/Chart.yaml.
|
||||
dependencies:
|
||||
- name: alloy
|
||||
version: 1.12.1
|
||||
repository: https://grafana.github.io/helm-charts
|
||||
|
||||
type: application
|
||||
version: 0.1.0
|
||||
appVersion: "v1.19.2"
|
||||
@@ -0,0 +1,175 @@
|
||||
# -----------------------------------------------------------------------------
|
||||
# Grafana Alloy — l'agent de collecte, un pod par nœud.
|
||||
# -----------------------------------------------------------------------------
|
||||
# POURQUOI ALLOY ET PAS PROMTAIL (l'arbitrage de tools#38, mesuré le 2026-09-07)
|
||||
#
|
||||
# Relevé sur l'index du dépôt Helm de Grafana lui-même
|
||||
# (`curl https://grafana.github.io/helm-charts/index.yaml`) :
|
||||
#
|
||||
# chart versions dernière publication `deprecated:` dans l'index
|
||||
# promtail 141 2025-10-31 true
|
||||
# alloy 57 2026-08-27 (absent)
|
||||
# loki 344 2026-08-10 (absent)
|
||||
#
|
||||
# Promtail n'est pas « en fin de vie bientôt » : son chart porte le drapeau
|
||||
# `deprecated: true` dans l'index, et sa dernière publication a plus de dix mois.
|
||||
# Déployer AUJOURD'HUI, sur une installation NEUVE, un agent que l'amont a déjà
|
||||
# rangé, c'est se donner une dette à échéance connue pour économiser de la
|
||||
# mémoire — et l'économie, elle, est à vérifier, pas à supposer.
|
||||
#
|
||||
# Le coût réel d'Alloy sur CE matériel est mesuré après déploiement et reporté
|
||||
# dans la PR ; c'est ce que le plafond `resources` ci-dessous encadre.
|
||||
#
|
||||
# ARM64 : vérifié au registre, manifeste multi-plateforme (jeton anonyme
|
||||
# Docker Hub) — `grafana/alloy:v1.19.2` publie linux/amd64, **linux/arm64**,
|
||||
# ppc64le, s390x. `grafana/loki:3.6.12` publie amd64, **arm64**, arm/v7.
|
||||
# -----------------------------------------------------------------------------
|
||||
alloy:
|
||||
controller:
|
||||
# C'est déjà le défaut du chart ; on l'écrit parce que c'est LA décision
|
||||
# structurante — un agent par nœud, donc trois fois le coût mémoire.
|
||||
type: daemonset
|
||||
|
||||
alloy:
|
||||
# -- Le montage de /var/log : c'est par là que l'agent lit les journaux.
|
||||
# On tail des FICHIERS plutôt que d'interroger l'API du kubelet : sur trois
|
||||
# Pi, faire transiter tous les journaux par l'API du cluster ajouterait au
|
||||
# serveur d'API une charge qu'il n'a pas à porter.
|
||||
mounts:
|
||||
varlog: true
|
||||
# k3s utilise containerd, pas Docker : ce montage-là ne servirait à rien.
|
||||
dockercontainers: false
|
||||
|
||||
# ⚠ LA MÉMOIRE EST LA RESSOURCE RARE, ET UN DAEMONSET LA PREND TROIS FOIS.
|
||||
# Mesuré le 2026-09-07 avant tout déploiement : pi1 79 %, pi2 109 %,
|
||||
# pi3 58 % de leur mémoire ALLOUABLE. pi2 est en surengagement — c'est
|
||||
# précisément le nœud où un agent de trop bascule la machine.
|
||||
#
|
||||
# Le plafond n'est donc pas une formalité : il est ce qui garantit que
|
||||
# l'agent meurt AVANT le service qu'il observe. Un OOM d'Alloy est un
|
||||
# incident de collecte ; un OOM de MinIO ou de pgbouncer est un incident
|
||||
# tout court.
|
||||
resources:
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 128Mi
|
||||
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
|
||||
|
||||
# Pas de grappe : chaque agent lit SON nœud, il n'a rien à coordonner.
|
||||
clustering:
|
||||
enabled: false
|
||||
|
||||
configMap:
|
||||
create: true
|
||||
# -----------------------------------------------------------------------
|
||||
# La configuration Alloy. Trois étages : découvrir, lire, pousser.
|
||||
# -----------------------------------------------------------------------
|
||||
content: |-
|
||||
// ÉTAGE 1 — découvrir les pods de CE nœud, et de lui seul.
|
||||
//
|
||||
// ⚠ Sans le filtre par nœud, chacun des trois agents découvrirait les
|
||||
// pods des TROIS nœuds, chercherait leurs fichiers en local, n'en
|
||||
// trouverait aucun pour les deux autres, et referait ce travail en
|
||||
// boucle. Le filtre se pose côté serveur d'API (`field`), pas en
|
||||
// relabel : ce qui n'est pas envoyé ne coûte rien.
|
||||
discovery.kubernetes "pods_du_noeud" {
|
||||
role = "pod"
|
||||
|
||||
selectors {
|
||||
role = "pod"
|
||||
field = "spec.nodeName=" + sys.env("HOSTNAME")
|
||||
}
|
||||
}
|
||||
|
||||
// ÉTAGE 2 — traduire les métadonnées Kubernetes en étiquettes Loki,
|
||||
// et fabriquer le chemin du fichier journal.
|
||||
//
|
||||
// ⚠ LES ÉTIQUETTES SONT LE SEUL INDEX DE LOKI, ET CHAQUE COMBINAISON
|
||||
// DISTINCTE EST UN FLUX. On garde ce par quoi on cherche vraiment
|
||||
// (namespace, pod, conteneur, nœud) et RIEN de ce qui varie sans
|
||||
// qu'on l'interroge : mettre ici une étiquette à forte cardinalité
|
||||
// (un identifiant de requête, un horodatage) est la façon classique
|
||||
// de faire tomber un Loki. Le reste du contenu reste cherchable en
|
||||
// plein texte, simplement non indexé.
|
||||
discovery.relabel "journaux_de_pods" {
|
||||
targets = discovery.kubernetes.pods_du_noeud.targets
|
||||
|
||||
rule {
|
||||
source_labels = ["__meta_kubernetes_namespace"]
|
||||
target_label = "namespace"
|
||||
}
|
||||
rule {
|
||||
source_labels = ["__meta_kubernetes_pod_name"]
|
||||
target_label = "pod"
|
||||
}
|
||||
rule {
|
||||
source_labels = ["__meta_kubernetes_pod_container_name"]
|
||||
target_label = "container"
|
||||
}
|
||||
rule {
|
||||
source_labels = ["__meta_kubernetes_node_name"]
|
||||
target_label = "node"
|
||||
}
|
||||
rule {
|
||||
source_labels = ["__meta_kubernetes_pod_label_app_kubernetes_io_name"]
|
||||
target_label = "app"
|
||||
}
|
||||
|
||||
// Le chemin réel posé par le kubelet :
|
||||
// /var/log/pods/<ns>_<pod>_<uid>/<conteneur>/0.log
|
||||
// On vise par l'UID (unique) et le nom du conteneur.
|
||||
rule {
|
||||
source_labels = ["__meta_kubernetes_pod_uid", "__meta_kubernetes_pod_container_name"]
|
||||
separator = "/"
|
||||
action = "replace"
|
||||
replacement = "/var/log/pods/*$1/*.log"
|
||||
target_label = "__path__"
|
||||
}
|
||||
}
|
||||
|
||||
// ÉTAGE 3 — lire les fichiers, décoder le format CRI, pousser.
|
||||
local.file_match "journaux_de_pods" {
|
||||
path_targets = discovery.relabel.journaux_de_pods.output
|
||||
}
|
||||
|
||||
loki.source.file "journaux_de_pods" {
|
||||
targets = local.file_match.journaux_de_pods.targets
|
||||
forward_to = [loki.process.journaux_de_pods.receiver]
|
||||
}
|
||||
|
||||
// ⚠ containerd n'écrit PAS du JSON de Docker : chaque ligne est
|
||||
// « <horodatage> <flux> <F|P> <message> ». Sans `stage.cri`, l'horodatage
|
||||
// stocké serait celui de la LECTURE et non celui de l'écriture — ce qui
|
||||
// ruinerait précisément l'usage qui motive ce lot : dater une panne.
|
||||
loki.process "journaux_de_pods" {
|
||||
stage.cri {}
|
||||
|
||||
forward_to = [loki.write.loki.receiver]
|
||||
}
|
||||
|
||||
loki.write "loki" {
|
||||
endpoint {
|
||||
url = "http://loki.tools.svc.cluster.local:3100/loki/api/v1/push"
|
||||
}
|
||||
}
|
||||
|
||||
# L'agent a besoin de LIRE les pods du serveur d'API pour les découvrir.
|
||||
# Le chart pose un ClusterRole en lecture seule (pods, nodes, services,
|
||||
# endpoints) — rien qui écrive.
|
||||
rbac:
|
||||
create: true
|
||||
|
||||
serviceAccount:
|
||||
create: true
|
||||
|
||||
# Pas de collecte de métriques d'Alloy par Prometheus pour l'instant : le
|
||||
# ServiceMonitor suppose l'opérateur Prometheus, que ce cluster n'a pas
|
||||
# (le chart `prometheus` d'ici est le chart communautaire, pas l'opérateur).
|
||||
serviceMonitor:
|
||||
enabled: false
|
||||
|
||||
ingress:
|
||||
enabled: false
|
||||
@@ -10,3 +10,9 @@ tools:
|
||||
plausible: {}
|
||||
prometheus: {}
|
||||
minio: {}
|
||||
# La collecte de journaux (tools#38). Deux applications parce que ce sont
|
||||
# deux charts amont, et parce qu'on redémarre l'agent sans toucher au
|
||||
# magasin — mais elles ne valent rien l'une sans l'autre : `alloy` pousse
|
||||
# vers le service que `loki` publie.
|
||||
loki: {}
|
||||
alloy: {}
|
||||
|
||||
@@ -573,6 +573,21 @@ grafana: &grafana_config
|
||||
url: http://prometheus-server.tools.svc.cluster.local
|
||||
access: proxy
|
||||
isDefault: true
|
||||
# Les journaux du cluster (tools#38). Le chart `loki` d'à côté déploie
|
||||
# le binaire unique ; `alloy` y pousse ce que disent les pods.
|
||||
# ⚠ `loki.auth_enabled: false` côté serveur : aucun en-tête
|
||||
# X-Scope-OrgID à porter ici. Si l'authentification multi-locataire
|
||||
# était rallumée, cette source de données cesserait de répondre et il
|
||||
# faudrait lui ajouter `httpHeaderName1: X-Scope-OrgID`.
|
||||
- name: Loki
|
||||
type: loki
|
||||
url: http://loki.tools.svc.cluster.local:3100
|
||||
access: proxy
|
||||
isDefault: false
|
||||
jsonData:
|
||||
# La rétention posée dans loki/values.yaml. Grafana s'en sert pour
|
||||
# ne pas proposer une fenêtre que le magasin ne peut plus servir.
|
||||
maxLines: 1000
|
||||
# - name: CloudWatch
|
||||
# type: cloudwatch
|
||||
# access: proxy
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
# Patterns to ignore when building packages.
|
||||
# This supports shell glob matching, relative path matching, and
|
||||
# negation (prefixed with !). Only one pattern per line.
|
||||
.DS_Store
|
||||
# Common VCS dirs
|
||||
.git/
|
||||
.gitignore
|
||||
.bzr/
|
||||
.bzrignore
|
||||
.hg/
|
||||
.hgignore
|
||||
.svn/
|
||||
# Common backup files
|
||||
*.swp
|
||||
*.bak
|
||||
*.tmp
|
||||
*.orig
|
||||
*~
|
||||
# Various IDEs
|
||||
.project
|
||||
.idea/
|
||||
*.tmproj
|
||||
.vscode/
|
||||
@@ -0,0 +1,35 @@
|
||||
apiVersion: v2
|
||||
name: loki
|
||||
description: >-
|
||||
Le garde-mémoire des journaux du cluster — Loki en binaire unique, stockage
|
||||
fichier sur Longhorn. Ce qu'un pod a dit continue de se lire après sa mort.
|
||||
|
||||
# ⚠ PAS de dépendance au registre Helm interne, CONTRAIREMENT à grafana et
|
||||
# prometheus — et c'est délibéré.
|
||||
#
|
||||
# La bibliothèque `tool` ne sert QUE via les gabarits `templates/helm-chart*.yaml`,
|
||||
# eux-mêmes gardés par `{{- if eq .Values.tool.kind "HelmChart" -}}`. Avec
|
||||
# `kind: SubChart` — le mode de grafana, de prometheus, et le nôtre — ces
|
||||
# gabarits ne rendent RIEN : la bibliothèque est un poids mort.
|
||||
#
|
||||
# Or ce poids mort a un coût mesuré : le runner de CI ne résout pas
|
||||
# `gitea.arcodange.lab` (relevé du 2026-09-07, run 6728, `curl` code 6). Un
|
||||
# repli sur `GITHUB_SERVER_URL` a été posé dans `helmcharts.yaml`, mais il reste
|
||||
# un point de panne EN AMONT du `helm template`. Si la dépendance ne se
|
||||
# télécharge pas, l'étape qui éprouve VRAIMENT ce chart ne s'exécute jamais et
|
||||
# le job meurt sur une cause étrangère au chart.
|
||||
#
|
||||
# On ne dépend donc que de `grafana.github.io`, dont le même relevé a constaté
|
||||
# qu'il répond depuis ce runner. Le jour où l'on veut basculer en
|
||||
# `kind: HelmChart` (CRD k3s), on rajoute la dépendance ET les deux gabarits.
|
||||
dependencies:
|
||||
- name: loki
|
||||
version: 7.3.0
|
||||
repository: https://grafana.github.io/helm-charts
|
||||
|
||||
type: application
|
||||
version: 0.1.0
|
||||
# ⚠ 3.6.11, PAS 3.6.12. L'index Helm annonce `appVersion: 3.6.12` pour le chart
|
||||
# 7.3.0, mais le chart épingle `loki.image.tag: 3.6.11` dans ses valeurs — et
|
||||
# c'est le tag qui est tiré. Vérifié sur le pod déployé.
|
||||
appVersion: "3.6.11"
|
||||
@@ -0,0 +1,234 @@
|
||||
# -----------------------------------------------------------------------------
|
||||
# Loki — binaire unique, stockage fichier, sur trois Raspberry Pi.
|
||||
# -----------------------------------------------------------------------------
|
||||
# ⚠⚠ LES DÉFAUTS AMONT SONT ÉCRITS POUR UN CLUSTER DE SERVEURS, PAS POUR CECI.
|
||||
# Mesurés sur le chart 7.3.0 (`helm show values grafana/loki --version 7.3.0`) :
|
||||
#
|
||||
# deploymentMode SimpleScalable → read + write + backend, 3 jeux
|
||||
# chunksCache.enabled true → un memcached à …
|
||||
# chunksCache.allocatedMemory 8192 → … 8 Gio, sur un nœud qui en
|
||||
# alloue 5,6 (pi2)
|
||||
# resultsCache.enabled true → un second memcached
|
||||
# gateway.enabled true → un nginx de plus
|
||||
# lokiCanary.enabled true → un DaemonSet de plus
|
||||
# test.enabled true → un pod de test
|
||||
# loki.commonConfig.replication_factor 3 → 3 exemplaires de chaque flux
|
||||
# loki.storage.type s3 → un magasin objet qu'on n'a pas
|
||||
# loki.auth_enabled true → multi-locataire (en-tête
|
||||
# X-Scope-OrgID exigé à chaque appel)
|
||||
#
|
||||
# Laisser ces défauts, c'est exactement la deuxième propriété de tools#38
|
||||
# violée : « la collecte ne doit pas faire tomber ce qu'elle observe ». Chaque
|
||||
# `false` ci-dessous est donc une décision, pas une omission.
|
||||
# -----------------------------------------------------------------------------
|
||||
loki:
|
||||
# -- Un seul processus, une seule réplique. Le reste des modes est éteint plus bas.
|
||||
deploymentMode: SingleBinary
|
||||
|
||||
loki:
|
||||
# Locataire unique : personne d'autre que le homelab n'écrit ici. Laisser
|
||||
# `true` obligerait chaque requête (et chaque source de données Grafana) à
|
||||
# porter un en-tête X-Scope-OrgID, pour aucun bénéfice.
|
||||
auth_enabled: false
|
||||
|
||||
commonConfig:
|
||||
path_prefix: /var/loki
|
||||
# -- UNE réplique de chaque flux : il n'y a qu'un ingesteur.
|
||||
# Le défaut amont (3) ferait refuser toute écriture, faute de quorum.
|
||||
replication_factor: 1
|
||||
|
||||
storage:
|
||||
type: filesystem
|
||||
filesystem:
|
||||
chunks_directory: /var/loki/chunks
|
||||
rules_directory: /var/loki/rules
|
||||
# ⚠ PAS de `admin_api_directory` ici. Le chart l'accepte (il est dans
|
||||
# ses valeurs par défaut), mais le binaire OSS le REFUSE :
|
||||
# failed parsing config: field admin_api_directory not found in
|
||||
# type common.FilesystemConfig
|
||||
# C'est un champ de l'édition entreprise (GEL). Mesuré : le pod part en
|
||||
# CrashLoopBackOff, 3 redémarrages en 4 min. Le chart ne valide pas la
|
||||
# config qu'il écrit — seul le démarrage réel le dit.
|
||||
|
||||
# ⚠ 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.
|
||||
schemaConfig:
|
||||
configs:
|
||||
- from: "2026-09-07"
|
||||
store: tsdb
|
||||
object_store: filesystem
|
||||
schema: v13
|
||||
index:
|
||||
prefix: loki_index_
|
||||
period: 24h
|
||||
|
||||
# ⚠⚠ UNE RÉTENTION QUI NE SUPPRIME RIEN EST UNE RÉTENTION QUI MENT.
|
||||
# `limits_config.retention_period` seul ne fait RIEN : c'est le compacteur
|
||||
# qui efface, et il ne le fait que si `retention_enabled` est vrai. Le
|
||||
# couple est indissociable — l'un sans l'autre laisse le volume grossir
|
||||
# jusqu'à saturation, en silence.
|
||||
compactor:
|
||||
working_directory: /var/loki/compactor
|
||||
retention_enabled: true
|
||||
delete_request_store: filesystem
|
||||
|
||||
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.
|
||||
reject_old_samples: true
|
||||
reject_old_samples_max_age: 720h
|
||||
max_cache_freshness_per_query: 10m
|
||||
split_queries_by_interval: 15m
|
||||
query_timeout: 300s
|
||||
volume_enabled: true
|
||||
# Débit mesuré du cluster : ~305 Mio/jour TOUS pods confondus, soit
|
||||
# ~3,6 Kio/s. Les bornes amont (4 Mio/s par flux) sont hors sujet ici ;
|
||||
# on les laisse, elles ne mordent pas.
|
||||
allow_structured_metadata: true
|
||||
|
||||
# Pas de vitrine : personne d'extérieur n'interroge ce Loki.
|
||||
analytics:
|
||||
reporting_enabled: false
|
||||
|
||||
singleBinary:
|
||||
replicas: 1
|
||||
persistence:
|
||||
enabled: true
|
||||
# ⚠ DEUX StorageClass portent le drapeau `(default)` sur ce cluster
|
||||
# (`local-path` ET `longhorn`, mesuré le 2026-09-07). Un PVC sans classe
|
||||
# explicite est donc un tirage au sort — et `local-path` ne survit pas au
|
||||
# déplacement du pod, ce qui viderait la mémoire qu'on vient de bâtir.
|
||||
# On NOMME la classe.
|
||||
storageClass: longhorn
|
||||
# 30 j × 305 Mio/j = 8,9 Gio BRUTS ; Loki compresse (facteur 5 à 10 sur
|
||||
# du journal), donc 0,9 à 1,8 Gio attendus. 10 Gi laisse 5 à 10× de marge
|
||||
# pour la croissance de kadans, sans immobiliser le disque.
|
||||
size: 10Gi
|
||||
resources:
|
||||
requests:
|
||||
cpu: 100m
|
||||
memory: 256Mi
|
||||
limits:
|
||||
# Pas de limite CPU : l'étranglement d'un compacteur est pire que sa
|
||||
# lenteur. La mémoire, elle, est PLAFONNÉE — c'est la ressource rare
|
||||
# (pi2 mesuré à 109 % de son allouable le 2026-09-07).
|
||||
memory: 512Mi
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Tout ce qui suit existe pour un déploiement distribué. Ici, chacun de ces
|
||||
# blocs est du poids mort sur des Raspberry Pi — on les éteint NOMMÉMENT
|
||||
# plutôt que par un `deploymentMode` qui « devrait » suffire.
|
||||
# ---------------------------------------------------------------------------
|
||||
write: { replicas: 0 }
|
||||
read: { replicas: 0 }
|
||||
backend: { replicas: 0 }
|
||||
ingester: { replicas: 0 }
|
||||
distributor: { replicas: 0 }
|
||||
querier: { replicas: 0 }
|
||||
queryFrontend: { replicas: 0 }
|
||||
queryScheduler: { replicas: 0 }
|
||||
indexGateway: { replicas: 0 }
|
||||
compactor: { replicas: 0 }
|
||||
bloomPlanner: { replicas: 0 }
|
||||
bloomBuilder: { replicas: 0 }
|
||||
bloomGateway: { replicas: 0 }
|
||||
patternIngester: { replicas: 0 }
|
||||
ruler: { replicas: 0 }
|
||||
overridesExporter: { replicas: 0 }
|
||||
|
||||
# Les deux memcached. Le premier réclame 8 Gio à lui seul par défaut.
|
||||
chunksCache:
|
||||
enabled: false
|
||||
resultsCache:
|
||||
enabled: false
|
||||
|
||||
# Un nginx devant un service que seul Grafana interroge, depuis le cluster.
|
||||
gateway:
|
||||
enabled: false
|
||||
|
||||
# Un DaemonSet qui écrit des journaux pour vérifier qu'on lit les journaux :
|
||||
# trois pods de plus sur trois nœuds, pour une propriété que le sabotage de
|
||||
# la PR démontre mieux (écrire une ligne, tuer le pod, la relire).
|
||||
lokiCanary:
|
||||
enabled: false
|
||||
|
||||
test:
|
||||
enabled: false
|
||||
|
||||
# Le chart sait déployer SON PROPRE MinIO. On en a déjà un, et on n'en veut
|
||||
# pas ici : le stockage est le disque.
|
||||
minio:
|
||||
enabled: false
|
||||
|
||||
monitoring:
|
||||
dashboards:
|
||||
enabled: false
|
||||
rules:
|
||||
enabled: false
|
||||
serviceMonitor:
|
||||
enabled: false
|
||||
metricsInstance:
|
||||
enabled: false
|
||||
selfMonitoring:
|
||||
enabled: false
|
||||
grafanaAgent:
|
||||
installOperator: false
|
||||
|
||||
# Pas d'opérateur de déploiement progressif pour une réplique unique.
|
||||
rollout_operator:
|
||||
enabled: false
|
||||
|
||||
# ⚠ UN SECOND CONTENEUR SANS PLAFOND ANNULE LE PLAFOND DU PREMIER.
|
||||
# Le chart ajoute au pod un side-car `loki-sc-rules` (kiwigrid/k8s-sidecar)
|
||||
# qui surveille des ConfigMaps de règles d'alerte. Mesuré sur le premier
|
||||
# déploiement : il arrive avec `resources: {}` — ni requête ni limite — dans
|
||||
# un pod posé sur pi2, le nœud à 108 % de son allouable. On l'éteint : le
|
||||
# `ruler` est à 0 réplique, il n'y a aucune règle à ingérer, donc ce side-car
|
||||
# surveille des ConfigMaps qui n'existent pas.
|
||||
sidecar:
|
||||
rules:
|
||||
enabled: false
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# RETENTION — l'arbitrage, et la mesure qui le porte
|
||||
# -----------------------------------------------------------------------------
|
||||
# Mesuré le 2026-09-07 sur ce cluster, par l'API (donc ce que Loki ingérerait) :
|
||||
#
|
||||
# fenêtre de 10 min, tous pods : 2 182 015 octets
|
||||
# fenêtre de 1 h, tous pods : 7 897 505 octets
|
||||
#
|
||||
# Les deux instruments ne s'accordent pas (l'heure ne vaut que 0,60 fois six
|
||||
# fois les dix minutes) — et le désaccord est LE résultat. Par conteneur, le
|
||||
# rapport 1 h / 10 min vaut ~6 partout (débit stable) SAUF :
|
||||
#
|
||||
# kube-system/traefik ratio 1,18 → la fenêtre d'une heure est TRONQUÉE
|
||||
# tools/clickhouse-0 ratio 3,98 → tronquée aussi
|
||||
#
|
||||
# Vérifié directement, en demandant à chaque journal jusqu'où il remonte :
|
||||
#
|
||||
# traefik pod démarré il y a 12 j — journal remontant à 10 MINUTES
|
||||
# clickhouse pod démarré il y a 8 j — journal remontant à 2 MINUTES
|
||||
#
|
||||
# Autrement dit, les deux composants les plus bavards du cluster gardent entre
|
||||
# deux et dix minutes d'histoire. C'est l'issue tools#38 en un chiffre.
|
||||
#
|
||||
# Estimation corrigée (max(1 h, 10 min × 6) par conteneur, pour ne pas hériter
|
||||
# de la troncature) : 13 333 645 octets/h = 305 Mio/jour bruts.
|
||||
#
|
||||
# 30 j bruts 8,94 Gio
|
||||
# 30 j compressés (facteur 5) 1,79 Gio
|
||||
# 30 j compressés (facteur 10) 0,89 Gio
|
||||
#
|
||||
# POURQUOI 30 JOURS et pas 7 : les deux pannes qui motivent ce lot ont duré des
|
||||
# SEMAINES avant d'être vues (la mise à l'abri de kadans#1033) ou trois jours
|
||||
# (tools#36). Une rétention de 7 jours aurait perdu le début des deux. 30 jours
|
||||
# couvre le délai réel entre « ça casse » et « quelqu'un s'en aperçoit », et
|
||||
# coûte 1 à 2 Gio — sur 99 Gio libres au plus serré des trois nœuds Longhorn.
|
||||
#
|
||||
# ⚠ CE QUI RENDRAIT CE CHIFFRE FAUX : la mesure est une photo d'un mardi
|
||||
# après-midi. Elle ne dit rien d'un pod qui part en boucle d'erreur, cas où le
|
||||
# débit d'un seul conteneur peut dépasser à lui seul tout le reste du cluster.
|
||||
# La marge de 5 à 10× est là pour ça, pas pour la croissance ordinaire.
|
||||
# -----------------------------------------------------------------------------
|
||||
Reference in New Issue
Block a user