Monitorización Escalable: Prometheus y Thanos 2026

La monitorización de infraestructuras modernas ha evolucionado más allá de las soluciones monolíticas. Cuando gestionas cientos de nodos, microservicios en Kubernetes y cargas de trabajo híbridas, una sola instancia de Prometheus se queda corta. Aquí es donde entra Thanos, un componente que transforma Prometheus en un sistema de monitorización distribuida capaz de ofrecer métricas escalables y alta disponibilidad sin sacrificar simplicidad.

¿Por qué necesitas una solución distribuida?

Prometheus, por sí solo, es excelente para recopilar métricas en tiempo real. Sin embargo, presenta limitaciones críticas en entornos grandes:

Retención local: Los datos se almacenan en disco local. Si el nodo falla, pierdes el historial.
Escalado vertical: Para manejar más métricas, necesitas una máquina más grande. No escala horizontalmente de forma nativa.
Alta disponibilidad: Ejecutar dos réplicas de Prometheus no garantiza consistencia; cada una recopila datos de forma independiente.
Vista global: Consultar métricas de múltiples clústeres requiere configuraciones complejas o proxies.

Thanos resuelve estos problemas proporcionando un plano de control global que se acopla a tus instancias de Prometheus existentes.

Componentes clave de Thanos

Thanos no es un reemplazo de Prometheus, sino un conjunto de componentes que se integran con él. Los principales son:

1. Sidecar

Se ejecuta junto a cada instancia de Prometheus. Sube los datos de series temporales a un almacenamiento externo (normalmente S3 o GCS) y expone una API de consulta unificada.

2. Store Gateway

Actúa como puerta de enlace al almacenamiento de objetos. Permite consultar datos históricos (con retención ilimitada) como si fueran locales.

3. Query Frontend

Capa de caché y división de consultas. Mejora el rendimiento de consultas complejas y reduce la carga en los componentes posteriores.

4. Compactor

Disminuye el tamaño de los datos en el almacenamiento de objetos mediante la reducción de resolución (downsampling) y la desduplicación.

5. Receiver (opcional)

Permite recibir métricas directamente sin Prometheus, útil para entornos serverless o edge computing.

Arquitectura de alta disponibilidad con Thanos

El objetivo principal de la monitorización distribuida es que ningún punto único de fallo detenga la visibilidad de tu sistema. Con Thanos, esto se logra mediante:

Desduplicación de métricas: Ejecutas dos instancias de Prometheus idénticas (con el mismo external_labels). Thanos Query detecta y elimina duplicados automáticamente.
Almacenamiento de objetos: Los datos se persisten en un bucket S3. Si un Prometheus muere, el Sidecar ya ha subido los datos.
Balanceo de consultas: Thanos Query puede escalar horizontalmente para manejar un alto volumen de peticiones.

[INFO] La clave de la alta disponibilidad en Thanos es el uso de --replica-label. Este flag le dice al Query cuándo dos métricas son idénticas y debe mostrar solo una.

Implementación paso a paso

Requisitos previos

Docker y Docker Compose (o Kubernetes).
Acceso a un bucket S3 (MinIO para pruebas locales).
Conocimientos básicos de PromQL.

1. Configurar Prometheus con Sidecar

Crea un archivo docker-compose.yml con un Prometheus configurado para retención local mínima y etiquetas de replicación:

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:v2.47.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=2h' # Retención local corta
      - '--storage.tsdb.min-block-duration=2h'
      - '--storage.tsdb.max-block-duration=2h'

  sidecar:
    image: quay.io/thanos/thanos:v0.32.0
    command:
      - 'sidecar'
      - '--tsdb.path=/prometheus'
      - '--prometheus.url=http://prometheus:9090'
      - '--objstore.config-file=/etc/thanos/objstore.yml'
    volumes:
      - ./objstore.yml:/etc/thanos/objstore.yml

El archivo objstore.yml define el bucket:

type: S3
config:
  bucket: thanos-bucket
  endpoint: minio:9000
  access_key: minioadmin
  secret_key: minioadmin
  insecure: true
  signature_version2: false

2. Desplegar Thanos Query

Añade un servicio Query que unifique las fuentes:

  query:
    image: quay.io/thanos/thanos:v0.32.0
    command:
      - 'query'
      - '--http-address=0.0.0.0:9090'
      - '--store=sidecar:10901'  # Conecta al Sidecar local
      - '--store=store-gateway:10901' # Conecta al Store Gateway
    ports:
      - "9091:9090"

3. Añadir Store Gateway y Compactor

Para consultar datos históricos del bucket:

  store-gateway:
    image: quay.io/thanos/thanos:v0.32.0
    command:
      - 'store'
      - '--data-dir=/data'
      - '--objstore.config-file=/etc/thanos/objstore.yml'

  compactor:
    image: quay.io/thanos/thanos:v0.32.0
    command:
      - 'compact'
      - '--data-dir=/data'
      - '--objstore.config-file=/etc/thanos/objstore.yml'
      - '--wait'

[WARNING] No ejecutes el Compactor en modo --wait sin antes tener datos en el bucket. De lo contrario, consumirá CPU en bucle.

Beneficios de las métricas escalables

Una vez desplegado, obtienes:

Retención ilimitada: Los datos históricos se almacenan en S3. Puedes consultar métricas de hace meses sin ocupar disco local.
Escalado horizontal: Añade más instancias de Prometheus con Sidecar. Thanos Query las descubrirá automáticamente.
Vista global: Desde un solo endpoint (query:9090) puedes ver métricas de todos tus clústeres, incluso si están en regiones distintas.
Reducción de costes: Con el Compactor, los datos antiguos se agregan (downsampling) a resoluciones de 5 minutos o 1 hora, reduciendo el almacenamiento hasta un 90%.

Casos de uso reales

Monitorización multi-clúster Kubernetes

Imagina que gestionas 5 clústeres de Kubernetes en diferentes proveedores cloud. Con Prometheus vanilla, tendrías que abrir 5 dashboards diferentes. Con Thanos:

Cada clúster tiene un Prometheus con Sidecar.
Todos suben métricas al mismo bucket S3.
Un único Thanos Query expone una API unificada.
Grafana se conecta a ese Query y muestra todas las métricas con etiquetas de clúster.

Archivado de métricas para auditoría

Muchas empresas necesitan retener métricas durante 1 año o más por cumplimiento normativo. Thanos permite:

Retención local de 2 horas en Prometheus.
Retención en S3 de 365 días.
Consultas históricas sin impacto en el rendimiento de recolección.

[TIP] Usa --retention.resolution-raw en el Compactor para conservar datos sin procesar durante 30 días, y luego aplica downsampling para el resto.

Consideraciones de rendimiento

Aunque Thanos es robusto, requiere ajustes:

Latencia de consulta: Consultar datos históricos desde S3 es más lento que desde disco local. Usa Query Frontend con caché para mitigarlo.
Coste de almacenamiento: S3 tiene costes de salida de datos. Si haces muchas consultas a datos antiguos, considera usar Store Gateway con caché de disco SSD.
Complejidad operativa: Thanos añade 4-5 nuevos componentes. En Kubernetes, usa Helm Charts (bitnami/thanos) para simplificar el despliegue.

Alternativas y cuándo no usar Thanos

Cortex / Mimir: Más adecuados si necesitas multi-tenencia nativa o ya usas Grafana Cloud.
VictoriaMetrics: Ofrece mejor rendimiento de escritura y menor uso de RAM, pero menos ecosistema de integraciones.
Prometheus solo: Si tu infraestructura es pequeña (< 10 nodos) y no necesitas retención larga, no añadas complejidad.

Conclusión

La monitorización distribuida con Prometheus y Thanos es la combinación ideal para equipos que buscan alta disponibilidad y métricas escalables sin atarse a un proveedor específico. Thanos extiende Prometheus de manera elegante, permitiendo retención ilimitada, consultas globales y tolerancia a fallos, todo con herramientas open source.

La implementación requiere una inversión inicial en configuración y almacenamiento de objetos, pero los beneficios a largo plazo en términos de fiabilidad y visibilidad son incalculables. Si tu stack de monitorización ya sufre de falta de escalabilidad o puntos únicos de fallo, Thanos es la solución que estabas buscando.