La mayoría de las herramientas de logging y monitorización son sistemas a los que envías datos. Prometheus, en cambio, se construye en torno a hacer pull: sale a buscar a las cosas que monitoriza según un calendario y les pide sus números actuales. Esa decisión de diseño da forma a casi todo lo demás sobre cómo se despliega y se configura, y esta guía cubre la arquitectura que se deriva de ella.

Scraping: un pull en lugar de un push

Prometheus envía periódicamente una petición HTTP a cada sistema que monitoriza y lee de vuelta una instantánea de los valores de métricas actuales de ese sistema. Prometheus llama a esto scraping, y a cada cosa que consulta target. Un scrape lleva solo los valores de ese momento; no hay historial en la respuesta: Prometheus es lo que convierte una secuencia de scrapes, tomados a intervalos, en un historial.

El modelo pull tiene una consecuencia práctica: todo lo que Prometheus monitoriza necesita exponer un endpoint HTTP (/metrics por convención) que devuelva sus valores actuales en un formato que Prometheus entienda, en lugar de que Prometheus necesite un listener de entrada para cada posible fuente que le envíe datos.

Targets: aplicaciones instrumentadas y exporters

Un target cae en una de dos categorías:

• Aplicaciones instrumentadas directamente. Tu propio servicio, usando una de las librerías cliente oficiales de Prometheus, rastrea y expone sus propias métricas de forma nativa en un endpoint /metrics.
• Exporters, para todo lo que no expone (o no puede exponer) métricas de Prometheus por sí mismo: una base de datos, un host Linux, un dispositivo de red. Un exporter es un pequeño proceso que se ejecuta junto a lo que se monitoriza, traduciendo sus estadísticas nativas al formato de Prometheus. node_exporter para métricas a nivel de host (CPU, memoria, disco, red) y cAdvisor para métricas por contenedor son dos de los más usados.

Como el formato de exposición es deliberadamente un texto simple (que cubre la siguiente guía), escribir un exporter, o incluso construir métricas a mano sin librería cliente, es realista incluso para algo sin soporte oficial de Prometheus.

Encontrar targets: configuración estática o service discovery

Prometheus necesita una lista de targets que consultar. Para un puñado de hosts estables, listarlos a mano en el archivo de configuración de Prometheus está bien. Para cualquier cosa más grande o más dinámica, máquinas y contenedores que van y vienen, eso se vuelve rápidamente impracticable de mantener a mano. Prometheus se integra en cambio con mecanismos de service discovery, DNS, la API server de Kubernetes, APIs de proveedores de nube y otros, para construir y actualizar continuamente su lista de targets de forma automática a medida que cambia el entorno.

Almacenamiento: la base de datos local de series temporales

Las muestras recopiladas aterrizan en la propia base de datos local de series temporales (TSDB) de Prometheus en disco. Por defecto, Prometheus retiene 15 días de datos; es un flag configurable (--storage.tsdb.retention.time), no un límite rígido, pero 15 días bastan para la inmensa mayoría de la resolución de problemas real, ya que la mayoría de los incidentes se comparan con minutos u horas atrás, rara vez con meses. Para retención a largo plazo o un almacén centralizado entre muchos servidores Prometheus, Prometheus también puede configurarse para reenviar (remote-write) muestras a un sistema de almacenamiento externo con compromisos distintos a los de su propia TSDB local.

Qué rodea al servidor central

Unos cuantos componentes completan una configuración típica:

• Alertmanager es un componente aparte al que Prometheus entrega las alertas que se están disparando. Deduplica, agrupa y las enruta a correo, Slack, PagerDuty o lo que configures, desacoplando “detectar un problema” de “decidir a quién se notifica y cómo”.
• Grafana (o la interfaz web incluida de Prometheus, u otras herramientas) es como normalmente explorarías y visualizarías los datos; Prometheus en sí se centra en recopilar y almacenar métricas de forma fiable, no en ser la capa de dashboards.
• PromQL, el lenguaje de consultas de Prometheus, es sobre lo que se construyen tanto los dashboards de Grafana como las propias reglas de alertas de Prometheus. Las alertas y los dashboards no son dos sistemas distintos pegados entre sí; son dos consumidores del mismo lenguaje de consultas sobre los mismos datos. Las guías posteriores de esta serie cubren directamente el modelo de datos y PromQL.

Juntando las piezas

   ┌──────────────┐     recopila (scrape) por HTTP    ┌──────────────┐
   │  Servidor    │ ───────────────────────────────▶ │    Target    │
   │  Prometheus  │                                    │ (/metrics)   │
   └──────┬───────┘                                    └──────────────┘
          │ almacena las muestras en
          ▼
   TSDB local (retención de 15 d por defecto)
          │
   ┌──────┴───────────────┬───────────────────────┐
   ▼                       ▼                       ▼
reglas de alerta        consultas PromQL        remote write
 que se disparan        (Grafana, ad hoc)        (opcional, almacenamiento externo)
   │
   ▼
Alertmanager → correo / Slack / PagerDuty / ...

Todo lo que viene después, alertas, dashboards, depuración ad hoc, lee de la misma TSDB que llena el scraping. El resto de esta serie empieza por lo que realmente se almacena en ella.