arcodange-org/tools
1
0
Fork 0
Code Issues 13 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Prometheus : up vide n'est pas un défaut de scrutation. La configuration, le RBAC et la découverte sont sains ; c'est le stockage (récidive de #36) #59

New Issue
Open
opened 2026-09-25 20:42:36 +02:00 by arcodange · 0 comments
arcodange commented 2026-09-25 20:42:36 +02:00
Owner
Copy Link
Copy Source

Le constat de départ

La requête up ne rend rien. L'hypothèse de départ était « Prometheus ne scrute rien » : configuration de scrutation vide, RBAC, surcharge des values, ou découverte cassée. Les quatre sont écartées. Relevé en lecture seule le 2026-09-25 entre 18 h 25 et 18 h 45 UTC. Rien n'a été modifié, et aucune PR n'est ouverte : il n'y a rien à corriger dans la configuration de scrutation.

Ce qui est sain

  • Configuration (ConfigMap tools/prometheus-server, rendue depuis prometheus/values.yaml, app ArgoCD prometheus en Synced) : 11 jobs, aucun metric_relabel_configs qui jetterait des séries.
    • kubernetes-nodes : kubelet, en :10250 direct avec le jeton du compte de service ;
    • kubernetes-nodes-cadvisor : /metrics/cadvisor ;
    • kubernetes-pods et kubernetes-pods-slow : annotations prometheus.io/scrape ;
    • kubernetes-service-endpoints et sa variante -slow : node-exporter et kube-state-metrics ;
    • kubernetes-api-servers, kubernetes-services, prometheus-pushgateway, kadans-worker-mac ;
    • prometheus : statique, localhost:9090.
  • RBAC (kubectl auth can-i --as=system:serviceaccount:tools:prometheus-server) : list/watch sur nodes, pods, endpoints, services et endpointslices, get sur nodes/metrics et nodes/proxy → yes partout.
  • Cibles découvrables et joignables :
    • services annotés : kube-dns, kube-state-metrics, node-exporter, step-issuer ;
    • pods annotés : cert-manager ×3, kadans-api, kadans-jobs ×2, traefik ;
    • depuis un pod de tools, wget sur les trois node-exporter (192.168.1.20{1,2,3}:9100), kube-state-metrics et le Pushgateway : les cinq rendent leurs métriques.

Le point qui tranche : le job prometheus est statique. Il n'a besoin ni de découverte ni de RBAC. Dès que le TSDB accepte des échantillons, up{job="prometheus"} existe. Un up entièrement vide veut donc dire que Prometheus n'enregistre pas, pas qu'il ne scrute pas. C'est exactement la signature de #36 (« count(up) : aucune série, en face de 23 cibles annoncées vivantes », write to WAL: … input/output error).

Ce qui ne va pas : le stockage de pi3

  • Prometheus est à l'arrêt depuis 18 h 20 UTC. Le nouveau pod prometheus-server-86c78bd477-smm6m reste en ContainerCreating (plus de 20 min) : volume pvc-015eabf4… hasn't been attached yet. Le volume Longhorn est attaching, robustesse unknown. Côté longhorn-manager : invalid instance manager … state starting. L'instance-manager de pi3 a été recréé après des operation timeout: context deadline exceeded de Docker.
  • Avant : le pod précédent (…-kclw6) échouait déjà ses sondes. Readiness en délai dépassé vers 18 h 01, liveness vers 18 h 13 : Prometheus était bloqué, pas arrêté.
  • Noyau de pi3 (dmesg, lecture seule) : entre 18 h 18 et 18 h 23 UTC, sept systèmes de fichiers Longhorn voient leur journal ext4 abandonné, puis passent en lecture seule. Sont nommés dans le journal : minio (sdc), vault (sdi), loki (sdg), alertmanager (sdb), redis (sde). Pour sdh, sdd et sdj, le démontage n'a pas pu nettoyer le journal. Charge de pi3 : 58 à 71 pour 4 cœurs. Loki rend lui aussi input/output error : les journaux de l'ancien pod Prometheus sont donc illisibles.
  • Disque externe de pi3 à 82 %, disque Longhorn Schedulable=False : voir factory#64.
  • prometheus/values.yaml préfère pi3 (poids 100) et exclut pi2 (#51) : Prometheus ne peut aller que sur pi1 ou pi3.

Non vérifié, parce que le pod ne démarre pas : /api/v1/targets, et la ligne Scrape commit failed … write to WAL dans le journal de Prometheus. C'est ce qui prouverait le mécanisme de #36 pour aujourd'hui.

Ce qu'il faut décider (fondateur)

Le défaut est dans le stockage du TSDB, pas dans la scrutation. L'instrument qui doit raconter les incidents de disque vit sur le disque qui tombe en panne. Trois pistes, non exclusives :

  1. Une classe de stockage Longhorn à 1 réplique en dataLocality: strict-local pour Prometheus. Les entrées-sorties restent locales : il n'y a plus de délai moteur → réplica distant, qui est le mécanisme de #49, #52 et de factory#59. Ça rejoint la réponse « No need for replicas for homelab » et l'évaluation en cours pour MinIO. Le prix : l'historique est perdu si le nœud meurt, et il faut recréer le PVC (la classe d'un PVC est immuable).
  2. Sortir Prometheus de pi3, tant que son disque sature. Ce qui reste : pi1, qui porte le control-plane et où le volume avait déjà perdu son journal (#51).
  3. --storage.tsdb.retention.size (par exemple 6 GB pour le PVC de 8 Gi), en garde-fou contre un TSDB qui remplirait son volume. Ce n'est pas la cause relevée ici.

Vérifier quand Prometheus repart

kubectl --context default -n tools port-forward svc/prometheus-server 19090:80 &
# attendu : une vingtaine de séries (23 le 2026-09-07), jamais un vecteur vide
curl -s 'http://127.0.0.1:19090/api/v1/query?query=count(up)' | jq '.data.result'
# les cibles par job et par santé
curl -s http://127.0.0.1:19090/api/v1/targets \
  | jq -r '.data.activeTargets[] | "\(.labels.job) \(.health)"' | sort | uniq -c
# la signature de #36 (attendu : 0)
kubectl --context default -n tools logs deploy/prometheus-server -c prometheus-server | grep -c "Scrape commit failed"

Si count(up) est vide alors que /api/v1/targets liste des cibles up, c'est #36 : le WAL n'écrit plus. La réparation décrite dans #36 (détacher, puis rattacher le volume) s'applique.

Liens : #36 (même signature), #51 (déplacement sur pi3), #58 (MinIO sur pi3, même jour), factory#64 (disque de pi3), factory#63 (audit « sans disque »).

🤖 Generated with Claude Code

## Le constat de départ La requête `up` ne rend rien. L'hypothèse de départ était « Prometheus ne scrute rien » : configuration de scrutation vide, RBAC, surcharge des values, ou découverte cassée. **Les quatre sont écartées.** Relevé en lecture seule le 2026-09-25 entre 18 h 25 et 18 h 45 UTC. Rien n'a été modifié, et aucune PR n'est ouverte : il n'y a rien à corriger dans la configuration de scrutation. ## Ce qui est sain - **Configuration** (ConfigMap `tools/prometheus-server`, rendue depuis `prometheus/values.yaml`, app ArgoCD `prometheus` en `Synced`) : **11 jobs**, aucun `metric_relabel_configs` qui jetterait des séries. - `kubernetes-nodes` : kubelet, en `:10250` direct avec le jeton du compte de service ; - `kubernetes-nodes-cadvisor` : `/metrics/cadvisor` ; - `kubernetes-pods` et `kubernetes-pods-slow` : annotations `prometheus.io/scrape` ; - `kubernetes-service-endpoints` et sa variante `-slow` : node-exporter et kube-state-metrics ; - `kubernetes-api-servers`, `kubernetes-services`, `prometheus-pushgateway`, `kadans-worker-mac` ; - `prometheus` : **statique**, `localhost:9090`. - **RBAC** (`kubectl auth can-i --as=system:serviceaccount:tools:prometheus-server`) : `list`/`watch` sur nodes, pods, endpoints, services et endpointslices, `get` sur `nodes/metrics` et `nodes/proxy` → **yes** partout. - **Cibles découvrables et joignables** : - services annotés : kube-dns, kube-state-metrics, node-exporter, step-issuer ; - pods annotés : cert-manager ×3, kadans-api, kadans-jobs ×2, traefik ; - depuis un pod de `tools`, `wget` sur les trois node-exporter (`192.168.1.20{1,2,3}:9100`), kube-state-metrics et le Pushgateway : les cinq rendent leurs métriques. **Le point qui tranche** : le job `prometheus` est statique. Il n'a besoin ni de découverte ni de RBAC. Dès que le TSDB accepte des échantillons, `up{job="prometheus"}` existe. **Un `up` entièrement vide veut donc dire que Prometheus n'enregistre pas, pas qu'il ne scrute pas.** C'est exactement la signature de #36 (« `count(up)` : aucune série, en face de 23 cibles annoncées vivantes », `write to WAL: … input/output error`). ## Ce qui ne va pas : le stockage de pi3 - **Prometheus est à l'arrêt depuis 18 h 20 UTC.** Le nouveau pod `prometheus-server-86c78bd477-smm6m` reste en `ContainerCreating` (plus de 20 min) : `volume pvc-015eabf4… hasn't been attached yet`. Le volume Longhorn est `attaching`, robustesse `unknown`. Côté longhorn-manager : `invalid instance manager … state starting`. L'instance-manager de pi3 a été recréé après des `operation timeout: context deadline exceeded` de Docker. - **Avant** : le pod précédent (`…-kclw6`) échouait déjà ses sondes. Readiness en délai dépassé vers 18 h 01, liveness vers 18 h 13 : Prometheus était bloqué, pas arrêté. - **Noyau de pi3** (`dmesg`, lecture seule) : entre 18 h 18 et 18 h 23 UTC, **sept systèmes de fichiers Longhorn** voient leur journal ext4 abandonné, puis passent en lecture seule. Sont nommés dans le journal : minio (`sdc`), vault (`sdi`), loki (`sdg`), alertmanager (`sdb`), redis (`sde`). Pour `sdh`, `sdd` et `sdj`, le démontage n'a pas pu nettoyer le journal. Charge de pi3 : **58 à 71** pour 4 cœurs. Loki rend lui aussi `input/output error` : les journaux de l'ancien pod Prometheus sont donc illisibles. - **Disque externe de pi3 à 82 %**, disque Longhorn `Schedulable=False` : voir factory#64. - `prometheus/values.yaml` **préfère pi3** (poids 100) et **exclut pi2** (#51) : Prometheus ne peut aller que sur pi1 ou pi3. **Non vérifié**, parce que le pod ne démarre pas : `/api/v1/targets`, et la ligne `Scrape commit failed … write to WAL` dans le journal de Prometheus. C'est ce qui prouverait le mécanisme de #36 pour aujourd'hui. ## Ce qu'il faut décider (fondateur) Le défaut est dans le stockage du TSDB, pas dans la scrutation. L'instrument qui doit raconter les incidents de disque vit sur le disque qui tombe en panne. Trois pistes, non exclusives : 1. **Une classe de stockage Longhorn à 1 réplique en `dataLocality: strict-local`** pour Prometheus. Les entrées-sorties restent locales : il n'y a plus de délai moteur → réplica distant, qui est le mécanisme de #49, #52 et de factory#59. Ça rejoint la réponse « No need for replicas for homelab » et l'évaluation en cours pour MinIO. Le prix : l'historique est perdu si le nœud meurt, et il faut recréer le PVC (la classe d'un PVC est immuable). 2. **Sortir Prometheus de pi3**, tant que son disque sature. Ce qui reste : pi1, qui porte le control-plane et où le volume avait déjà perdu son journal (#51). 3. **`--storage.tsdb.retention.size`** (par exemple 6 GB pour le PVC de 8 Gi), en garde-fou contre un TSDB qui remplirait son volume. Ce n'est pas la cause relevée ici. ## Vérifier quand Prometheus repart ```bash kubectl --context default -n tools port-forward svc/prometheus-server 19090:80 & # attendu : une vingtaine de séries (23 le 2026-09-07), jamais un vecteur vide curl -s 'http://127.0.0.1:19090/api/v1/query?query=count(up)' | jq '.data.result' # les cibles par job et par santé curl -s http://127.0.0.1:19090/api/v1/targets \ | jq -r '.data.activeTargets[] | "\(.labels.job) \(.health)"' | sort | uniq -c # la signature de #36 (attendu : 0) kubectl --context default -n tools logs deploy/prometheus-server -c prometheus-server | grep -c "Scrape commit failed" ``` Si `count(up)` est vide alors que `/api/v1/targets` liste des cibles `up`, c'est #36 : le WAL n'écrit plus. La réparation décrite dans #36 (détacher, puis rattacher le volume) s'applique. Liens : #36 (même signature), #51 (déplacement sur pi3), #58 (MinIO sur pi3, même jour), factory#64 (disque de pi3), factory#63 (audit « sans disque »). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
arcodange
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arcodange-org/tools#59