À la fin de ce tutoriel, vous prolongerez Prometheus avec Thanos : object storage S3 en ca-central-1, sidecar (ou receive), Store Gateway, Querier et Compactor — pour interroger des mois de métriques sans exploser le disque local du TSDB.

Niveau : Intermédiaire · Temps estimé : 70–90 min · Versions cibles : Kubernetes 1.29+ · Helm 3.x · kube-prometheus-stack / Prometheus Operator · Thanos 0.36+ · AWS CLI v2 · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-prometheus-thanos · Série : WOW Observability / SRE · Mot-clé SEO : Prometheus Thanos rétention

← Connexe : Prometheus Grafana Kubernetes Helm · OpenTelemetry stack · Grafana Loki Tempo · Hub : Kubernetes / DevOps

Prérequis

  • Cluster Kubernetes lab (kind, k3d, minikube ou EKS jetable) avec kubectl admin et Helm 3
  • Notions Prometheus : scrape, TSDB, ServiceMonitor (lab Helm kube-prometheus-stack)
  • Compte AWS lab, profil lab, région forcée ca-central-1 ; droits S3 (CreateBucket, Put/Get/List/DeleteObject)
  • Budget d’alerte AWS activé — object storage + cluster : suppression obligatoire en fin de session
  • Aucun secret réel dans Git : placeholders uniquement
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
kubectl cluster-info
helm version

Vérifiez l’identité lab — jamais un compte de production. Sur un kind mononœud, allégez la rétention locale Prometheus (ex. 6–12 h) : Thanos portera l’historique long.

Ce que nous allons construire

Lab Prometheus + Thanos (ca-central-1)
  ├── Bucket S3 lab (BPA, encryption, région Canada)
  ├── Secret object-store (thanos.yaml) hors Git
  ├── Prometheus Operator + sidecar Thanos
  ├── Thanos Querier (vue fédérée)
  ├── Store Gateway (blocks S3)
  ├── Compactor (downsample + retention)
  ├── Grafana → datasource Querier
  └── Nettoyage : stack → objets S3 → bucket

(Schéma — alt : « Prometheus scrapes localement ; Thanos shippe les blocks vers S3 et Querier unifie le passé ».)

Objectif : garder 15 minutes de scrape « chaud » sur le disque du Pod, et des semaines/mois de métriques dans S3, interrogeables comme une seule Prometheus API.

Étape 1 — Pourquoi Thanos (vs TSDB local seul)

Prometheus stocke des time series sur disque local. C’est excellent pour le court terme (alertes, dashboards live), fragile pour l’historique long : PVC qui grossit, Pod qui ne scale pas horizontalement pour la rétention, perte de données si le volume disparaît.

Approche Forces Limites
TSDB local seul Simple, latence basse Rétention limitée ; HA = federation/complexe
Remote write vers autre TSDB Découplé Autre stack à opérer
Thanos + object storage Rétention longue cheap (S3), query unifiée, HA naturelle Plus de composants ; compaction à dimensionner

Thanos ne remplace pas Prometheus : il complète le cycle de vie des blocks (upload, query, compact, downsample). En 2026, c’est le pattern standard quand kube-prometheus-stack doit sortir du lab « 15 jours max ».

Étape 2 — Bucket S3 lab en ca-central-1

Créez un bucket unique (suffixe aléatoire) dans la région Canada, privé, Block Public Access, chiffrement SSE-S3 :

SUFFIX=$(openssl rand -hex 4)
BUCKET="lab-thanos-metrics-${SUFFIX}"
echo "BUCKET=${BUCKET}"

aws s3api create-bucket 
  --bucket "$BUCKET" 
  --region ca-central-1 
  --create-bucket-configuration LocationConstraint=ca-central-1

aws s3api put-public-access-block --bucket "$BUCKET" 
  --public-access-block-configuration 
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-encryption --bucket "$BUCKET" 
  --server-side-encryption-configuration 
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

aws s3api put-bucket-tagging --bucket "$BUCKET" 
  --tagging 'TagSet=[{Key=Project,Value=lab-thanos},{Key=Env,Value=lab}]'

Optionnel : lifecycle pour expirer les préfixes après N jours côté S3 (défense en profondeur si le Compactor rate).

Étape 3 — Config object-store (Secret Kubernetes)

Fichier local (jamais commit) :

# thanos-objstore.yaml — NE PAS COMMITTER
type: s3
config:
  bucket: lab-thanos-metrics-REPLACE
  endpoint: s3.ca-central-1.amazonaws.com
  region: ca-central-1
  access_key: REPLACE_ME
  secret_key: REPLACE_ME
  signature_version2: false

kubectl create namespace monitoring --dry-run=client -o yaml | kubectl apply -f -

kubectl -n monitoring create secret generic thanos-objstore 
  --from-file=objstore.yml=./thanos-objstore.yaml 
  --dry-run=client -o yaml | kubectl apply -f -

En prod EKS, préférez IRSA / Pod Identity et omettez access_key/secret_key (role IAM scoped s3:ListBucket, s3:GetObject, s3:PutObject, s3:DeleteObject sur ce bucket).

Étape 4 — Prometheus Operator + sidecar Thanos

Si kube-prometheus-stack n’est pas encore là, installez-le (values allégées lab). Activez ensuite le thanos sidecar sur le Prometheus CR :

# excerpt values / Prometheus CR
prometheus:
  prometheusSpec:
    retention: 12h
    retentionSize: 8GB
    thanos:
      objectStorageConfig:
        key: objstore.yml
        name: thanos-objstore
    # resources / storage adaptés au lab

helm repo add prometheus-community https://prometheus-community.github.io/charts
helm repo update
# upgrade --install selon votre release existante ; pinnez une version chart
kubectl -n monitoring get pods -l app.kubernetes.io/name=prometheus
kubectl -n monitoring get secret thanos-objstore

Attendu : conteneur thanos-sidecar à côté de prometheus ; logs sans erreur d’upload ; premiers blocks visibles après le prochain compact local (patience 2–3h en lab, ou forcez une rétention courte pour accélérer les tests).

Vérification S3 :

aws s3 ls "s3://${BUCKET}/" --recursive | head

Étape 5 — Querier, Store Gateway, Compactor

Déployez les composants Thanos (chart bitnami/thanos, chart officiel, ou manifests). Minimal lab :

  1. Store Gateway — lit les blocks dans S3 (même Secret objstore.yml)
  2. Querier — fan-out vers sidecar(s) + store ; expose l’API Prometheus compatible
  3. Compactor — compacte, downsample (5m / 1h), applique la retention globale

Exemple d’idée de flags Compactor (à adapter à votre chart) :

--objstore.config-file=/etc/thanos/objstore.yml
--retention.resolution-raw=30d
--retention.resolution-5m=90d
--retention.resolution-1h=1y
--consistency-delay=30m

kubectl -n monitoring get deploy,sts | grep -i thanos || true
kubectl -n monitoring port-forward svc/thanos-query 9090:9090
# Ouvrir http://127.0.0.1:9090 — Stores : sidecar + store-gateway Ready

Dans Grafana, créez (ou éditez) la datasource Prometheus : URL = service Querier (http://thanos-query.monitoring.svc:9090). Les dashboards Kubernetes existants continuent de fonctionner ; l’historique long apparaît dès que les blocks sont queryables.

Étape 6 — HA, déduplication et notes prod

Plusieurs replicas Prometheus + sidecars : le Querier déduplique via les labels externes (replica, prometheus_replica). Alignez externalLabels pour éviter les doubles séries.

Checklist prod courte :

  • Object storage versionné + MFA delete désactivés en lab ; en prod, policies IAM least-privilege + encryption KMS
  • Compactor unique (un seul writer) ; Querier/Store en HA
  • Alerting reste sur Prometheus « chaud » (low latency) ; queries longues / reporting via Thanos
  • Coût S3 : PUT fréquents + LIST ; downsample pour contenir les GET analytiques
  • Observez aussi les traces/logs : enchaînez OpenTelemetry et Loki/Tempo pour un trio metrics/logs/traces

Nettoyage (obligatoire)

Ordre : Thanos Deploy/STS → Prometheus/sidecar → Secret → objets S3 → bucket.

# Exemple — adaptez aux noms de release Helm
helm uninstall thanos -n monitoring 2>/dev/null || true
# Ou delete manifests Querier / Store / Compactor
kubectl -n monitoring delete secret thanos-objstore --ignore-not-found

# Vider puis supprimer le bucket lab
aws s3 rm "s3://${BUCKET}" --recursive
aws s3api delete-bucket --bucket "$BUCKET" --region ca-central-1

Sur kind, détruire le cluster ne supprime pas le bucket : vérifiez toujours S3 en ca-central-1.

Coûts du lab

Ressource Ordre de grandeur
S3 blocks lab (Go) Cents / mois si petit
Requêtes S3 PUT/GET Surveiller en lab bruyant
Nœuds K8s / EKS Dominante — delete vite un EKS oublié
Grafana + Prometheus Coût compute local au cluster

Activez une alerte budget ; taguez Project=lab-thanos.

Erreurs fréquentes

Symptôme Cause Correction
Sidecar upload fail Creds / région / endpoint Relire Secret ; ca-central-1 ; clock skew
Querier Stores=0 Service DNS / labels port-forward ; endpoints sidecar --grpc-address
Pas de blocks S3 Rétention locale trop longue Baisser retention ; attendre compact
Compactor crash loop Deux compactors Un seul replica ; lock dans le bucket
Doublons Grafana Pas de dedup labels externalLabels + querier dedup
AccessDenied S3 IAM trop strict ListBucket sur bucket ARN + objets /*

FAQ

Thanos remplace-t-il Prometheus ?
Non. Prometheus scrape et alerte ; Thanos gère rétention longue, query globale et HA storage.

Sidecar ou Receive ?
Sidecar : Prometheus Operator classique, blocks uploadés. Receive (remote write) : agents légers / multi-tenant. Ce lab privilégie le sidecar.

Combien de rétention locale garder ?
Assez pour survivre à une panne S3 courte et pour l’alerting (souvent 6–24 h en lab, 2–15 j en prod selon PVC).

Grafana doit-il pointer vers Prometheus ou Thanos ?
Pour l’historique long : Querier Thanos. Pour debug ultra-local du scrape : Prometheus reste utile.

Pourquoi ca-central-1 ?
Data residency Canada, latence lab alignée sur le reste des tutoriels DevOps Elastic Hayway.

Et Mimir / Cortex ?
Alternatives remote-write natives. Thanos reste le chemin le plus direct depuis un Prometheus Operator existant.

Quiz (3 questions)

1. Quel composant lit les blocks historiques dans S3 ?
– A. Alertmanager uniquement
– B. Store Gateway
– C. node-exporter

2. Pourquoi un seul Compactor ?
– A. Licence
– B. Éviter les races d’écriture / compaction concurrente sur l’object store
– C. Grafana l’impose

3. Où configurer le bucket S3 côté sidecar ?
– A. Dans etcd à la main
– B. Secret objectStorageConfig (objstore.yml) référencé par le Prometheus CR / values
– C. Uniquement dans Grafana

Réponses : 1‑B · 2‑B · 3‑B

Pour aller plus loin

Maillage WOW / Observability
Série WOW ×50 — Observability & SRE
Voisins wow-opentelemetry-stack · wow-grafana-loki-tempo · wow-sre-error-budgets · wow-incident-io-runbooks
Hubs live Kubernetes · DevOps (menus du site)

Meta publication (SEO) — Publish GO

  • Title SEO : Prometheus + Thanos : rétention longue S3 (lab 2026)
  • Meta description (≤ 160) : Prolongez Prometheus avec Thanos : sidecar, Store Gateway, Querier et Compactor sur S3 en ca-central-1. Lab rétention longue et Grafana unifié.
  • Image mise en avant : assets/web/devopelastichayway/cover-wow-prometheus-thanos-1200x630.webp
  • Cover alt : Thanos stocke les métriques Prometheus sur S3 pour une rétention longue
  • Catégorie : DevOps / Observability · Niveau : Intermédiaire
  • KW principal : Prometheus Thanos rétention · Secondaires : Thanos S3, Store Gateway, Querier Compactor, kube-prometheus-stack Thanos
  • Schema : HowTo + FAQPage + Article
  • URL cible : https://devopelastichayway.com/tutoriels/wow-prometheus-thanos/
  • Statut : Publish GO — feu vert Maître / Haythem, WP-CLI parent 5463
  • Region lab : ca-central-1

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.