Un Prometheus local stocke ses métriques sur le disque du nœud où il tourne, avec une rétention configurée en général sur quelques semaines : au-delà, les anciennes données sont purgées, pas archivées. Cette contrainte n’est pas un oubli de configuration, c’est une limite structurelle du modèle : un TSDB local n’est pas conçu pour retenir des années d’historique, ni pour répondre à une requête qui couvre plusieurs clusters Prometheus distincts à la fois.

La rétention locale, bornée par le disque du nœud

Chaque Prometheus gère son propre stockage local, dimensionné pour l’espace disque disponible sur le nœud qui l’héberge. Garder un an d’historique complet signifierait dimensionner ce disque en conséquence, une approche qui ne passe pas à l’échelle au-delà de quelques semaines à quelques mois, selon la cardinalité réelle du système surveillé.

# Rétention par défaut typique : quelques semaines,
# au-delà les blocs les plus anciens sont supprimés
--storage.tsdb.retention.time=15d

Une analyse de tendance sur plusieurs mois (une capacité qui grossit lentement, une saisonnalité annuelle) devient tout simplement impossible une fois que les données correspondantes ont été purgées, sans avertissement au moment de la purge elle-même.

Le sidecar Thanos : uploader vers de l’object storage sans changer Prometheus

Thanos ajoute un sidecar à chaque Prometheus existant, sans modifier sa configuration de base : ce sidecar télécharge périodiquement les blocs de données TSDB déjà écrits vers un stockage objet (S3, GCS, ou équivalent), où la rétention n’a plus de limite pratique liée au disque d’un seul nœud.

# Le sidecar Thanos tourne aux côtés de Prometheus,
# sans modifier sa configuration de scrape existante
containers:
  - name: prometheus
    image: prom/prometheus
  - name: thanos-sidecar
    image: thanosio/thanos
    args:
      - sidecar
      - --objstore.config-file=/etc/thanos/objstore.yaml

Le stockage objet coûte structurellement moins cher au gigaoctet que du disque rapide attaché à un nœud, ce qui rend une rétention de plusieurs années financièrement réaliste là où elle ne l’était pas sur du disque local seul.

La vue globale : interroger plusieurs Prometheus comme un seul

Le second problème que Thanos résout est distinct de la rétention : un cluster avec plusieurs Prometheus (un par région, un par équipe) ne permet nativement aucune requête qui les couvre tous à la fois. Le composant Thanos Querier expose une seule API compatible PromQL qui interroge en parallèle tous les Prometheus connus (via leurs sidecars) et fusionne les résultats, donnant l’illusion d’un unique Prometheus global.

# Une seule requête, exécutée en parallèle sur tous
# les Prometheus connus, fusionnée en un résultat unique
sum(rate(http_requests_total[5m])) by (region)

Le downsampling : réduire la précision pour garder l’historique abordable

Conserver des données à leur résolution native (un point toutes les 15 ou 30 secondes) sur plusieurs années représente un volume de stockage objet considérable, même à un coût par gigaoctet plus faible. Thanos applique un downsampling automatique sur les données anciennes (agrégées à 5 minutes, puis à 1 heure au-delà d’un certain âge), un compromis assumé : les tendances à long terme restent visibles, le détail à la seconde près sur un incident vieux de deux ans ne l’est plus, un compromis rarement pertinent pour ce type d’historique.

À retenir

Un Prometheus local est structurellement limité en rétention par le disque du nœud qui l’héberge, une contrainte qui devient un vrai problème dès qu’une analyse de tendance dépasse quelques semaines. Thanos résout ce point via un sidecar qui déporte les blocs TSDB vers de l’object storage, à coût par gigaoctet nettement inférieur, tout en résolvant un second problème distinct : une vue de requête unifiée sur plusieurs Prometheus séparés. Le downsampling automatique rend cette rétention longue durée abordable, au prix d’une précision réduite sur les données anciennes, un arbitrage qui s’impose dès qu’une fiabilité et observabilité doit tenir sur plusieurs clusters et plusieurs années d’historique, pas seulement sur un cluster unique à courte mémoire.