Monitorización Prometheus Thanos 2025: Multi-cloud y Escalabilidad

La administración de infraestructuras distribuidas en múltiples nubes (multi-cloud) ha pasado de ser una opción a una necesidad para empresas que buscan alta disponibilidad, soberanía de datos y reducción de costes. Sin embargo, gestionar la observabilidad en este entorno fragmentado presenta un desafío monumental: silos de métricas, latencia de red y falta de una visión unificada.

Para superar estos obstáculos, la combinación de Prometheus, Grafana y Thanos se ha convertido en el estándar de facto. No hablamos de una simple instalación, sino de una arquitectura de monitorización multi-cloud diseñada para escalar horizontalmente, retener datos históricos durante años y ofrecer resiliencia ante fallos regionales.

En este artículo, exploraremos en profundidad cómo desplegar y optimizar este stack para clusters multi-cloud, garantizando que tu equipo de operaciones tenga visibilidad total sin comprometer el rendimiento.

El problema de la monitorización en entornos multi-cloud

Antes de profundizar en la solución, entendamos el problema raíz. En un escenario multi-cloud típico (por ejemplo, AWS + GCP + on-premise), cada proveedor ofrece su propio servicio de monitorización (CloudWatch, Stackdriver, etc.). Esto genera:

Fragmentación de datos: No hay un único panel de control.
Costes de egress elevados: Transferir métricas entre nubes puede ser prohibitivo.
Retención limitada: Prometheus por sí solo no escala bien para almacenar métricas de más de 30 días.
Alta disponibilidad compleja: Un fallo en una región puede dejar ciegos a los operadores.

Aquí es donde Thanos entra en juego, actuando como una capa de agregación global que transforma Prometheus de una herramienta local a un sistema de monitoreo global.

Arquitectura de referencia: Prometheus + Thanos + Grafana

La arquitectura se compone de tres capas lógicas, cada una con responsabilidades claras.

Capa de recolección: Prometheus en cada cluster

Cada cluster (sea en AWS, GCP o on-prem) ejecuta su propia instancia de Prometheus en modo sidecar o statefulset. Este Prometheus local es responsable de:

Scrapeo de métricas de servicios, nodos y componentes de Kubernetes.
Alerting local de baja latencia (usando Alertmanager).
Almacenamiento temporal (por defecto 15 días).

[TIP] Configura --storage.tsdb.retention.time=30d en cada Prometheus para dar margen a Thanos antes de que los datos se compacten.

Capa de agregación global: Thanos

Thanos no reemplaza a Prometheus, sino que lo extiende. Sus componentes clave son:

Thanos Sidecar: Se conecta al Prometheus local y sube los bloques TSDB a un almacenamiento de objetos (S3, GCS, MinIO).
Thanos Store Gateway: Expone los datos históricos desde el almacenamiento de objetos.
Thanos Compactor: Deduplica, compacta y aplica retention a largo plazo sobre los bloques.
Thanos Query: Componente frontal que implementa la API de Prometheus de forma federada, unificando datos de múltiples Sidecars y Store Gateways.

Capa de visualización: Grafana

Grafana se conecta a Thanos Query como fuente de datos. Esto permite:

Crear dashboards que crucen métricas de diferentes nubes.
Usar variables de plantilla para seleccionar clusters o regiones.
Aprovechar alertas basadas en datos globales.

Despliegue paso a paso de Thanos en multi-cloud

A continuación, te presento una guía práctica para desplegar Thanos en un entorno multi-cloud con Kubernetes.

1. Preparar el almacenamiento de objetos común

Elige un bucket S3 (o compatible) que sea accesible desde todas las nubes. Por ejemplo, usando MinIO on-premise o un bucket S3 con políticas de acceso cross-cloud.

# thanos-bucket-config.yaml
type: S3
config:
  bucket: "thanos-metrics-global"
  endpoint: "s3.amazonaws.com"
  access_key: "AKIA..."
  secret_key: "..."
  insecure: false
  signature_version2: false

2. Desplegar Thanos Sidecar junto a cada Prometheus

Cada clúster debe tener un deployment de Prometheus con un sidecar de Thanos.

# prometheus-with-sidecar.yaml (fragmento)
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: prometheus
spec:
  template:
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.45.0
        args:
          - '--storage.tsdb.retention.time=30d'
          - '--storage.tsdb.path=/data'
      - name: thanos-sidecar
        image: quay.io/thanos/thanos:v0.32.0
        args:
          - 'sidecar'
          - '--tsdb.path=/data'
          - '--objstore.config-file=/etc/thanos/bucket.yaml'
          - '--prometheus.url=http://localhost:9090'
        volumeMounts:
          - name: data
            mountPath: /data
          - name: bucket-config
            mountPath: /etc/thanos

[WARNING] Asegúrate de que el sidecar tenga acceso de escritura al bucket. Si usas IAM roles (en AWS), asigna la política adecuada al ServiceAccount.

3. Desplegar Thanos Store Gateway y Query

En una ubicación central (por ejemplo, un cluster de gestión en AWS), despliega:

Store Gateway: Lee bloques del bucket y los sirve a Query.
Query: Expone la API unificada.

# Despliegue rápido con Helm
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install thanos bitnami/thanos \
  --set query.enabled=true \
  --set storegateway.enabled=true \
  --set compactor.enabled=true \
  --set objstoreConfig="type: S3\nconfig:\n  bucket: thanos-metrics-global"

4. Conectar Grafana a Thanos Query

En Grafana, añade una fuente de datos de tipo Prometheus con la URL apuntando al servicio de Thanos Query (ej: http://thanos-query:9090). Activa la opción "Prometheus type" como Thanos.

Optimización de la escalabilidad y el rendimiento

La escalabilidad es el punto fuerte de Thanos, pero requiere ajustes finos.

Compresión y deduplicación

El Thanos Compactor es crítico. Sin él, los bloques subidos por cada sidecar se acumulan sin compactar. Configúralo para que ejecute deduplicación basada en réplicas.

# Configuración del compactor
compactor:
  retention.resolution-raw: 30d
  retention.resolution-5m: 180d
  retention.resolution-1h: 1y
  dedup.func: max

Estrategias de query

Para evitar saturar Thanos Query con peticiones lentas:

Usa query sharding si tienes muchos store gateways.
Implementa query frontend para cachear resultados frecuentes.
Limita el rango de tiempo en los dashboards de Grafana (no consultes 1 año en un panel de 5 minutos).

[INFO] Thanos Query soporta --endpoint para conectar múltiples store gateways. Usa DNS SRV para descubrimiento dinámico.

Alta disponibilidad en multi-cloud

Para evitar un punto único de fallo, despliega Thanos Query en al menos dos regiones diferentes, con un balanceador de carga global (como AWS Global Accelerator o Cloudflare) delante. Cada Query debe conocer todos los Store Gateways.

Casos de uso reales y troubleshooting

Ejemplo 1: Comparativa de rendimiento entre nubes

Un dashboard que muestre node_cpu_seconds_total agregado por proveedor cloud permite identificar qué nube está degradada.

# PromQL para Thanos
sum by (cloud_provider) (
  rate(node_cpu_seconds_total{mode="idle"}[5m])
)

Ejemplo 2: Alertas globales

Usa Grafana Alerting con Thanos como fuente para lanzar alertas que solo se disparen si el mismo error ocurre en más del 50% de los clusters.

Problemas comunes y soluciones

Métricas duplicadas: Asegúrate de que el compactor tenga --dedup.replica-label configurado (por ejemplo, replica).
Lentitud en queries históricas: Usa la resolución de 5m o 1h en dashboards de largo plazo.
Costes de almacenamiento: Configura retention agresiva en el compactor y usa almacenamiento de objetos con clases de almacenamiento por niveles (S3 Glacier para datos > 1 año).

Conclusión

La combinación de Prometheus, Thanos y Grafana no solo resuelve el problema de la monitorización multi-cloud, sino que establece una base sólida para la escalabilidad y la resiliencia. Thanos actúa como el pegamento que convierte silos de métricas en un único lago de datos global, accesible y consultable en tiempo real.

Implementar esta arquitectura requiere planificación, especialmente en la configuración de redes y permisos entre nubes, pero el retorno de inversión es inmediato: equipos de operaciones con visibilidad total, alertas precisas y capacidad de análisis histórico sin límites prácticos.

[TIP FINAL] No subestimes la fase de pruebas. Crea un cluster de desarrollo multi-cloud (puedes usar cuentas gratuitas de AWS, GCP y Azure) antes de ponerlo en producción. La complejidad de la red y los costes de egress te sorprenderán.

Con esta guía, estás listo para llevar la observabilidad de tu infraestructura al siguiente nivel.