Thanos : Prometheus en HA et rétention longue

Un Prometheus seul, c'est parfait jusqu'au jour où on lui demande ce pour quoi il n'a pas été conçu. Garder un an d'historique. Survivre à la perte d'un nœud sans trou dans les courbes. Donner une vue unique sur dix clusters. Là, les limites tombent d'un coup, et elles sont structurelles, pas une question de tuning.

Prometheus stocke ses séries dans une TSDB locale, sur le disque de la machine. C'est rapide, simple, et ça borne tout : la rétention est limitée par le disque, il n'y a pas de haute disponibilité native, et chaque instance ne voit que ses propres cibles. Pour passer ces murs sans changer d'outil de collecte, on ajoute Thanos par-dessus.

Le premier mur, c'est la rétention. La TSDB locale grossit avec le temps et la cardinalité. Garder six mois de métriques fines sur un parc dense, c'est des centaines de Go sur un disque local qu'il faut sauvegarder, dimensionner, surveiller. Au-delà de quelques semaines, le modèle local devient coûteux et fragile.

Le deuxième mur, c'est la haute disponibilité. La pratique courante pour ne pas perdre de données, c'est de lancer deux Prometheus identiques qui scrapent les mêmes cibles. Sauf qu'on se retrouve alors avec deux jeux de données quasi identiques mais pas tout à fait synchrones, et rien pour les fusionner proprement à la lecture. On a de la redondance, pas de la haute disponibilité exploitable.

Le troisième mur, c'est la vue globale. Chaque Prometheus est une île. Pour répondre à « quelle est la latence p99 sur l'ensemble de la plateforme », il faut interroger chaque instance et recoller les résultats à la main. Ça ne passe pas à l'échelle. Sur ces trois points, on a posé le socle dans notre guide sur la stack Prometheus, Grafana et Alertmanager ; Thanos est ce qu'on ajoute quand ce socle ne suffit plus.

Thanos n'est pas un bloc monolithique. C'est un ensemble de composants qu'on assemble selon le besoin, chacun avec un rôle précis.

Le Sidecar se déploie à côté de chaque Prometheus. Il a deux jobs : exposer les données du Prometheus local via la StoreAPI, l'interface commune de Thanos, et téléverser les blocs TSDB vers un object store au fur et à mesure que Prometheus les produit, toutes les deux heures. C'est lui qui fait sortir les données du disque local vers un stockage durable.

Le Store Gateway fait l'inverse : il lit les blocs depuis l'object store et les expose, eux aussi, via la StoreAPI. Il indexe les séries et met en cache les blocs les plus interrogés pour accélérer les requêtes sur l'historique. C'est le composant qui rend l'historique longue durée interrogeable sans le rapatrier sur disque local.

Le Querier est le cerveau de lecture. Il interroge toutes les sources qui parlent StoreAPI, les Sidecars pour les données récentes et les Store Gateways pour l'historique, puis fait le fan-out et fusionne les résultats. C'est lui qui produit la vue globale et qui déduplique les réplicas HA. Son interface ressemble à celle de Prometheus, on requête en PromQL comme d'habitude.

Le Compactor travaille en arrière-plan sur l'object store. Il compacte les blocs, déduplique, et surtout applique le downsampling et la rétention. C'est un composant à part, qui ne doit tourner qu'en un seul exemplaire par bucket pour éviter la corruption.

Restent deux composants optionnels. Le Ruler évalue les règles d'enregistrement et d'alerte sur les données globales plutôt que sur une seule instance. Et le Receive propose un modèle push : au lieu que les Sidecars exposent les Prometheus en pull, les Prometheus poussent leurs données vers un point central. Le modèle push via Receive simplifie certains cas, multi-tenant ou réseaux où le pull est compliqué, mais il déplace la complexité vers un composant central à dimensionner. Le modèle Sidecar pull reste le défaut le plus simple à opérer.

C'est le point qui résout le deuxième mur. Quand deux Prometheus scrapent les mêmes cibles, on les étiquette avec un label de réplica distinct. Le Querier sait alors que ces deux jeux de données sont des copies du même périmètre, et il les fusionne à la lecture en éliminant les doublons. Si un réplica a un trou parce qu'il a redémarré, l'autre comble le trou.

Le résultat, c'est une vraie continuité : la perte d'un Prometheus ne laisse aucun trou dans les courbes, parce que son jumeau couvre la même période et que le Querier recolle les deux. La redondance brute de deux instances devient enfin de la haute disponibilité exploitable.

Toute la rétention longue de Thanos repose sur un object store compatible S3 : AWS S3, GCS, Azure Blob, ou un MinIO auto-hébergé. Les blocs y vivent durablement, à un coût au Go bien inférieur au disque rapide local, et la durabilité est déléguée au stockage objet plutôt qu'aux disques de chaque Prometheus.

C'est un choix d'architecture qui a des conséquences. L'object store devient le composant critique de la rétention longue : sa disponibilité et sa latence conditionnent les requêtes sur l'historique. Pour un déploiement souverain ou on-premise, MinIO fait le travail, on a détaillé son exploitation dans notre guide sur MinIO comme stockage S3 sur Kubernetes. Et la gestion du cycle de vie des blocs, expiration et archivage, suit la même logique que celle qu'on a posée pour les politiques de cycle de vie S3.

Le Compactor fait du downsampling sur trois niveaux de résolution. Les données brutes, telles que scrapées. Une version agrégée à 5 minutes. Une version agrégée à 1 heure. On définit une rétention différente par niveau : par exemple, garder le brut quelques semaines, le 5 minutes quelques mois, le 1 heure un an ou plus.

La logique est simple : personne n'a besoin de la résolution à 15 secondes pour regarder une tendance sur l'année dernière. Une donnée horaire suffit pour ça. Attention au contresens fréquent : le downsampling ne fait pas gagner d'espace disque, il en consomme plutôt, parce que Thanos garde les trois résolutions en parallèle. Son but n'est pas la place, c'est la vitesse. Une requête sur un an balaie les agrégats horaires au lieu de millions de points bruts, et répond en une fraction du temps. L'économie de stockage, elle, vient de la rétention différenciée par résolution : on garde le brut peu de temps, les agrégats 5 minutes puis 1 heure de plus en plus longtemps. Le piège classique : oublier que le Compactor doit être unique par bucket. En lancer deux sur le même object store, c'est de la corruption de blocs assurée.

Thanos n'est pas la seule réponse au problème. VictoriaMetrics vise le même besoin avec une philosophie opposée, et le choix entre les deux dépend d'où vous partez.

Le contraste tient en une ligne. Thanos se greffe sur du Prometheus existant sans le remplacer, au prix de plusieurs composants à opérer. VictoriaMetrics est plus simple à déployer et plus dense en ressources, mais c'est un système à part qui change votre modèle de stockage et votre stratégie de reprise, puisqu'il pose les données sur du block storage et non sur de l'object store. Mimir, dans la même famille, vise la très grande échelle multi-tenant, au prix d'une architecture distribuée plus lourde à opérer que les deux autres.

Ce qu'on retient pour trancher. Si vous avez déjà du Prometheus en production et que le besoin, c'est d'ajouter la vue globale et la rétention longue sans tout refondre, Thanos est le bon choix : il se pose par-dessus l'existant via les Sidecars, vous gardez votre collecte, vos règles, vos dashboards. Si vous partez d'une feuille blanche et que la priorité, c'est la simplicité d'exploitation et la densité, VictoriaMetrics comme TSDB de supervision est le pari le plus économe en effort. Déjà du Prometheus et besoin global ou long terme, c'est Thanos ; greenfield qui veut la simplicité, c'est VictoriaMetrics.

Opérer Thanos en production, c'est tenir un Compactor unique, dimensionner l'object store, régler la rétention par niveau et garantir que la déduplication HA ne laisse aucun trou. Si votre supervision a besoin de passer à la haute disponibilité et à la rétention longue sans y consacrer une équipe, on peut concevoir et opérer la stack en infogérance.

• Thanos documentation : doc officielle, vue d'ensemble des composants et de l'architecture HA plus rétention longue.
• Thanos Sidecar : rôle du Sidecar, exposition StoreAPI et téléversement des blocs TSDB vers l'object store toutes les deux heures.
• Thanos Compactor : compaction, downsampling 5 minutes et 1 heure, déduplication, contrainte d'un seul Compactor par bucket.
• Improving HA and long-term storage for Prometheus using Thanos (AWS Open Source Blog) : déploiement Thanos sur EKS avec S3, montage des composants.
• VictoriaMetrics FAQ : positionnement face à Thanos, déduplication, modèle de stockage et empreinte ressources.