Prometheus es un eccosistema de monitorización y alertas de código abierto diseñado específicamente para entornos dinámicos y nativos de la nube. Desde su creación, se ha consolidado como el estándar de facto para la observabilidad en Kubernetes y arquitecturas de microservicios, gracias a su capacidad para gestionar series temporales de datos de forma eficiente.

Este sistema destaca por su enfoque en el registro de métricas puramente numéricas. Es ideal tanto para el seguimiento de infraestructura (servidores, red) como para la monitorización de servicios específicos. Aunque es extremadamente potente para analizar tendencias y el estado de salud de un sistema mediante consultas multidimensionales, no está diseñado para escenarios que requieran una precisión absoluta del 100%, como sistemas de facturación detallada, ya que su modelo de recolección de datos prioriza la disponibilidad sobre la consistencia perfecta en cada muestra.

Componentes y Arquitectura del Ecosistema

La arquitectura de Prometheus es modular y la mayoría de sus componentes están escritos en Go, lo que facilita su despliegue como binarios estáticos. Los elementos principales son:

• Prometheus Server: El núcleo del sistema que se encarga de recolectar las métricas mediante un modelo de "pull" (extracción), almacenarlas en una base de datos de series temporales (TSDB) y ejecutar reglas de agregación y alerta.
• Exporters: Agentes que extraen métricas de servicios que no exponen datos en formato Prometheus de forma nativa. Ejemplos comunes incluyen redis_exporter, postgres_exporter o el node_exporter para métricas de hardware.
• Pushgateway: Un componente intermedio utilizado para trabajos de corta duración (batch jobs) que no viven lo suficiente para ser "escrapeados" por el servidor.
• Alertmanager: Silencia, agrupa y envía notificaciones a través de diversos canales (email, Slack, PagerDuty) cuando se disparan las alertas definidas en el servidor.

Modelo de Datos y Series Temporales

En Prometheus, toda la información se almacena como una serie temporal: flujos de valores marcados con una estampa de tiempo que pertenecen a la misma métrica y al mismo conjunto de dimensiones etiquetadas.

El formato general de una métrica es el siguiente:
nombre_de_la_metrica{etiqueta1="valor1", etiqueta2="valor2"}

• Nombre de la métrica: Indica la característica general que se está midiendo. Por ejemplo, api_responses_total.
• Etiquetas (Labels): Permiten que el modelo de datos sea multidimensional. Una misma métrica con etiquetas diferentes genera una serie temporal distinta.

Ejemplo práctico:
api_responses_total{endpoint="/v1/login", status="200"}
api_responses_total{endpoint="/v1/login", status="500"}

Cada muestra en estas series consta de un valor numérico (float64) y un timestamp con precisión de milsiegundos.

Tipos de Métricas en Prometheus

Para adaptarse a diferentes necesidades de medición, las bibliotecas cliente de Prometheus ofrecen cuatro tipos de datos fundamentales:

1. Counter (Contador)

Es un valor acumulativo que representa un contador que solo puede aumentar o reiniciarse a cero (tras un reinicio del proceso). Es útil para medir peticiones totales, errores acumulados o tareas completadas.

# Ejemplo de uso de Counter
app_orders_processed_total{store="madrid"} 520
app_orders_processed_total{store="madrid"} 525

Se suele utilizar con la función rate() en PromQL para calcular la velocidad de incremento por segundo.

2. Gauge (Indicador)

Representa un valor numérico que puede subir y bajar arbitrariamente. Se utiliza para mediciones instantáneas como el uso de memoria, la temperatura o el número de hilos concurrentes.

# Ejemplo de uso de Gauge
system_memory_usage_bytes{instance="srv-01"} 1073741824
system_memory_usage_bytes{instance="srv-01"} 954204160

Con funciones como predict_linear(), es posible predecir el valor futuro de un Gauge basándose en su tendencia actual.

3. Histogram (Histograma)

Muestrea observaciones (generalmente duraciones de peticiones o tamaños de respuesta) y las recuenta en contenedores (buckets) configurables. Proporciona tres elementos:

• [métrica]_bucket{le="límite"}: El recuento acumulativo de observaciones menores o iguales al límite.
• [métrica]_sum: La suma total de todos los valores observados.
• [métrica]_count: El número total de eventos observados.

# Ejemplo de histograma para latencia de base de datos
db_query_duration_seconds_bucket{le="0.1"} 15
db_query_duration_seconds_bucket{le="0.5"} 30
db_query_duration_seconds_bucket{le="+Inf"} 35
db_query_duration_seconds_sum 12.5
db_query_duration_seconds_count 35

4. Summary (Resumen)

Similar al histograma, el Summary se utiliza para observar latencias o tamaños. La diferencia principal es que el Summary calcula los cuantiles directamente en el lado del cliente y los expone de forma explícita.

# Ejemplo de summary con cuantiles precalculados
http_request_duration_seconds{quantile="0.5"} 0.045
http_request_duration_seconds{quantile="0.9"} 0.120
http_request_duration_seconds{quantile="0.99"} 0.210
http_request_duration_seconds_sum 54.2
http_request_duration_seconds_count 1200

Mientras que los Histogramas permiten realizar agregaciones entre múltiples instancias de forma segura (usando histogram_quantile), los Summaries ofrecen una visión precisa de los cuantiles para un proceso individual sin requerir cálculos complejos en el servidor, aunque no pueden ser agregados estadísticamente entre varios nodos.