Qué son las Métricas y Cómo Usarlas en Observabilidad

Un importante minorista brasileño procesa más de 730 TB de datos en 6 meses a través de su infraestructura distribuida. Sin métricas estructuradas, sería imposible entender dónde está el cuello de botella de rendimiento entre millones de solicitudes. Las métricas son la base que transforma datos brutos en respuestas cuantitativas: “¿cuál es la latencia P95?”, “¿cuántos errores por minuto?”, “¿cuál es el rendimiento actual?”.

Prometheus es una de las herramientas más adoptadas para métricas y un proyecto graduado de CNCF. Las organizaciones con prácticas maduras de observabilidad típicamente comienzan con métricas como primer paso, ya que permiten la detección de anomalías en tiempo real y una respuesta más rápida a incidentes. Para más detalles, consulta la documentación oficial de Prometheus.

¿Qué son las Métricas?

Las métricas son valores numéricos observados y recolectados en el tiempo, generalmente organizados como series temporales. Representan el estado, comportamiento o rendimiento de sistemas y aplicaciones. Cada métrica consiste en:

1. Nombre: Identificador único (ej., http_requests_total)
2. Etiquetas/Dimensiones: Metadatos para filtrar (ej., {method="GET", status="200"})
3. Valor numérico: El valor observado o recolectado
4. Marca de tiempo: Momento de la recolección

Formato Prometheus (exposición):

http_requests_total{method="GET", status="200"} 12345 1622745600000
http_requests_total{method="POST", status="500"} 67 1622745600000

Diferencia: Métricas vs Logs vs Trazas

Más allá de saber qué medir, es importante entender cómo modelar esa medición. El modelo de instrumentación de Prometheus define cuatro tipos principales de métricas, cada una con características de uso específicas.

Los 4 Tipos de Métricas en el Modelo Prometheus

Counter, Gauge, Histogram y Summary son tipos de métricas en el modelo de instrumentación de Prometheus, ampliamente utilizados para representar diferentes patrones de medición. Otras herramientas pueden tener clasificaciones diferentes, pero estos conceptos son aplicables en diversos contextos.

Counter

Un valor que solo aumenta, reiniciándose a cero cuando el proceso se reinicia.

Características:

• Monótonamente creciente
• Se reinicia a cero al reiniciar el proceso
• Se usa para calcular tasas (ej., peticiones por segundo mediante rate())

Ejemplos:

• http_requests_total → Total de solicitudes HTTP
• errors_total → Total de errores
• bytes_transmitted_total → Bytes transmitidos

Uso típico:

# Tasa de solicitudes por segundo en los últimos 5 minutos
rate(http_requests_total[5m])

# Tasa de errores por minuto
rate(errors_total[1m]) * 60

Gauge

Un valor que puede subir o bajar, representando el estado actual.

Características:

• Instantánea del momento
• Puede subir o bajar libremente
• rate() no tiene sentido para gauges (no son monótonamente crecientes)
• Se usa para mostrar tendencias y estado actual

Ejemplos:

• cpu_usage_percent → Uso actual de CPU
• memory_bytes → Memoria en uso
• active_connections → Conexiones activas
• temperature_celsius → Temperatura

Uso típico:

# Valor actual (instantáneo)
cpu_usage_percent

# Promedio en los últimos 5 minutos
avg_over_time(cpu_usage_percent[5m])

# Máximo en la última hora
max_over_time(memory_bytes[1h])

Histogram

Distribuye los valores observados en buckets acumulativos predefinidos, permitiendo la estimación de cuantiles a partir de buckets definidos en tiempo de consulta.

Características:

• Los contadores de buckets son acumulativos (cada bucket incluye valores de buckets menores)
• Permite estimar cuantiles mediante histogram_quantile() en tiempo de consulta
• Permite agregar métricas de múltiples instancias
• Más flexible que summary para sistemas distribuidos

Exposición (tres series generadas):

# Contadores de buckets
http_request_duration_seconds_bucket{le="0.1"} 100
http_request_duration_seconds_bucket{le="0.5"} 150
http_request_duration_seconds_bucket{le="1.0"} 180
http_request_duration_seconds_bucket{le="+Inf"} 200

# Suma de todos los valores
http_request_duration_seconds_sum 123.4

# Conteo de observaciones
http_request_duration_seconds_count 200

Uso típico:

# Latencia P95 en los últimos 5 minutos (agregando múltiples instancias)
histogram_quantile(0.95,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

# Latencia P99
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Summary

Calcula cuantiles en el cliente (agente de instrumentación) en el momento de la observación.

Características:

• Los cuantiles se calculan en el lado del cliente
• Los cuantiles de summary no se pueden agregar correctamente entre instancias (a diferencia de los histogramas)
• Los cuantiles dependen de la configuración del cliente y pueden variar
• Menos flexible, pero evita el costo de almacenamiento de buckets

Exposición:

http_request_duration_seconds{quantile="0.5"} 0.12
http_request_duration_seconds{quantile="0.9"} 0.35
http_request_duration_seconds{quantile="0.99"} 0.89
http_request_duration_seconds_sum 123.4
http_request_duration_seconds_count 200

Uso típico:

# Valor directo (ya calculado)
http_request_duration_seconds{quantile="0.99"}

Histogram vs Summary: ¿Cuándo usar cada uno?

Después de entender los tipos de métricas, vale la pena conocer un conjunto de señales que se ha convertido en referencia para el monitoreo de servicios.

Golden Signals: Las Métricas Esenciales

Las golden signals son las cuatro métricas fundamentales descritas en el Google SRE Book. Proporcionan una visión esencial de la salud del servicio y son un punto de partida importante para observar sistemas distribuidos.

Nota: Las golden signals son un punto de partida útil. Los equipos maduros también rastrean métricas de negocio (conversión, ingresos) y métricas específicas de la aplicación (journeys críticos, embudos).

Los percentiles P95 y P99 son cuantiles utilizados frecuentemente para medir latencia. P95 significa que el 95% de las solicitudes tuvieron una latencia igual o inferior a ese valor; P99 representa el umbral para el 99% de las solicitudes.

Métricas SLI/SLO

SLI (Service Level Indicator): Métrica que mide un aspecto del servicio (ej., latencia P95).

SLO (Service Level Objective): Objetivo para el SLI (ej., P95 < 200ms en el 99.9% de las solicitudes).

Ejemplo:

Nota: Ejemplos simplificados con fines educativos. En la práctica, el SLI de disponibilidad debe reflejar la definición de éxito específica del servicio.

Después de entender los tipos de métricas y las señales esenciales, el siguiente paso es comprender cómo se representan estas métricas como series temporales.

Modelo de Datos de Prometheus

Series Temporales

Formato: <nombre_métrica>{<nombre_etiqueta>=<valor_etiqueta>, ...} <valor> <marca_tiempo>

Ejemplo:

http_requests_total{method="GET", status="200", endpoint="api/users"} 12345 1622745600000

Componentes:

Las etiquetas aumentan el poder analítico de las métricas, permitiendo filtrar y agrupar. Sin embargo, cada combinación única de etiquetas crea una nueva serie temporal — y esto puede escalar rápidamente.

Cardinalidad

Definición: Número de series temporales únicas generadas por una métrica.

Fórmula matemática:

S_total = |C₁| × |C₂| × ... × |Cₙ|

Donde:

• S_total = Número total de series
• Cᵢ = Conjunto de valores posibles para cada etiqueta i

Ejemplo práctico:

Métrica http_requests_duration_seconds con etiquetas:

• method: 4 valores (GET, POST, PUT, DELETE)
• status: 3 valores (2xx, 4xx, 5xx)
• endpoint: 100 valores

S_total = 4 × 3 × 100 = 1,200 series

Explosión de Cardinalidad

Problema: Las etiquetas con alta cardinalidad (ej., user_id, request_id) generan millones de series.

Mal ejemplo:

http_requests_total{user_id="12345", request_id="abc-123-def"}
# Resultado: millones de series → rendimiento degradado

Mitigaciones:

1. Evita IDs únicos como etiquetas (user_id, request_id, session_id)
2. Limita los valores posibles para cada etiqueta
3. Prefiere modelos agregables y evita multiplicar etiquetas de alta cardinalidad
4. Monitorea el volumen de series activas y valida el modelado antes de producción

Con la teoría de métricas, tipos y modelado de datos establecidos, vale la pena ver cómo se aplican estos conceptos en escenarios reales.

Casos de Uso Reales con Métricas

Marisa: Métricas de Rendimiento en Comercio Electrónico

Marisa es uno de los minoristas de moda más grandes de Brasil, con más de 11 millones de descargas de aplicaciones y el 70% de las ventas digitales concentradas en móvil.

Desafío:

• Monitorear el rendimiento del comercio electrónico con millones de solicitudes
• Comprender los cuellos de botella de latencia en tiempo real
• Correlacionar métricas de infraestructura con la experiencia del usuario

Métricas implementadas:

• Latencia P95: Tiempo de carga de página
• Rendimiento: Solicitudes por segundo durante picos
• Saturación: Uso de CPU/memoria en origen vs edge
• Tasa de error: Tasa de error HTTP por endpoint

Resultados verificados:

• 85% del tráfico servido por infraestructura distribuida
• 730 TB transferidos sin impacto en el origen
• 4.3 TB/día de imágenes procesadas y optimizadas
• Mejora en First Contentful Paint, Speed Index y Time to Interactive

Aprendizaje: Las métricas bien estructuradas permiten correlacionar el rendimiento de la infraestructura con la experiencia digital a escala, transformando datos operativos en decisiones de negocio.

B2W: Métricas de Seguridad a Escala

B2W Digital reúne algunas de las plataformas de comercio electrónico más grandes de América Latina, con 2 mil millones de visitas por año y 17 millones de clientes activos.

Desafío:

• Monitorear la seguridad en millones de conexiones diarias
• Detectar ataques en tiempo real
• Medir la efectividad de la mitigación

Métricas implementadas:

• Tasa de bloqueo: Solicitudes bloqueadas por segundo
• Tipos de ataque: DDoS, SQL injection, XSS por categoría
• Latencia de mitigación: Tiempo entre detección y bloqueo
• Tasa de error por regla: Efectividad de cada regla del Firewall

Resultados verificados:

• Millones de ataques bloqueados automáticamente
• Transformación de eventos en insights en tiempo real
• Integración de métricas con SIEM mediante Data Streaming
• Visibilidad completa del entorno en dashboards

Aprendizaje: Las métricas no son solo para rendimiento — también son fundamentales para la seguridad operativa, permitiendo medir la efectividad de la defensa y el tiempo de respuesta a incidentes.

Recolectar métricas es solo parte del trabajo. Extraer señales útiles depende de saber cómo agregar datos correctamente.

Agregación de Métricas

Tipos de Agregación

Agregación por Etiquetas

# Suma de solicitudes por método (agrega todos los endpoints)
sum by (method) (rate(http_requests_total[5m]))

# Latencia promedio por servicio
avg by (service) (latency_seconds)

# CPU máximo por región
max by (region) (cpu_usage_percent)

Agregación Temporal

# Promedio de una métrica en los últimos 5 minutos
avg_over_time(cpu_usage_percent[5m])

# Máximo en 1 hora
max_over_time(memory_bytes[1h])

# Mínimo en 1 día
min_over_time(active_connections[1d])

Con los conceptos de métricas, tipos, modelado y agregación presentados, las siguientes preguntas frecuentes ayudan a consolidar el aprendizaje.

Preguntas Frecuentes

¿Qué son las métricas?

Las métricas son valores numéricos observados y recolectados en el tiempo que representan el estado, comportamiento o rendimiento de los sistemas. Se organizan como series temporales con nombres, etiquetas y marcas de tiempo. Responden preguntas como “¿cuál es la tasa de error actual?”, “¿la latencia está dentro del SLO?”. Se diferencian de los logs (eventos) y las trazas (recorridos).

¿Cuáles son los 4 tipos de métricas?

Los cuatro tipos en el modelo de Prometheus son: Counter (valores que solo aumentan, ej., total de solicitudes), Gauge (valores que suben y bajan, ej., % CPU), Histogram (distribución en buckets acumulativos, permite estimación de cuantiles en tiempo de consulta) y Summary (cuantiles calculados en el cliente). Usa histogram por defecto para sistemas distribuidos.

¿Cuál es la diferencia entre counter y gauge?

Counter es un valor que solo aumenta, se reinicia a cero al reiniciar el proceso, se usa para calcular tasas (ej., rate()). Gauge es un valor que puede subir o bajar, representa el estado actual (ej., CPU, memoria). Usa counter para totales acumulados, gauge para valores instantáneos.

¿Qué son las golden signals?

Las golden signals son las cuatro métricas esenciales descritas por Google SRE: Latencia (tiempo de respuesta), Tráfico (demanda), Errores (tasa de fallos) y Saturación (uso de recursos). Proporcionan una visión esencial de la salud del servicio y son la base para SLIs/SLOs.

¿Qué es la cardinalidad en métricas?

La cardinalidad es el número de series temporales únicas generadas por una métrica, calculada como el producto de los valores posibles de cada etiqueta. La “explosión de cardinalidad” ocurre cuando etiquetas con muchos valores (user_id, request_id) generan millones de series, degradando el rendimiento.

Histogram o Summary: ¿cuándo usar cada uno?

Usa Histogram por defecto (agrega múltiples instancias y permite estimación de cuantiles en tiempo de consulta a partir de buckets definidos). Usa Summary solo cuando necesites cuantiles calculados en el cliente y no necesites agregarlos entre instancias. Histogram es más flexible y adecuado para sistemas distribuidos.

¿Cómo evitar la explosión de cardinalidad?

Evita etiquetas con valores únicos (user_id, request_id), limita los valores posibles de cada etiqueta, prefiere modelos agregables, reduce o agrega dimensiones de alta cardinalidad antes de la exposición cuando sea posible, y monitorea el número de series activas.

Conclusión

Las métricas son la base de la observabilidad. Transforman el comportamiento del sistema en datos numéricos que se pueden consultar, alertar y correlacionar. Los cuatro tipos del modelo de Prometheus — Counter, Gauge, Histogram y Summary — cubren la mayoría de los escenarios de monitoreo.

Conceptos clave:

• Métricas = Valores numéricos recolectados en el tiempo para representar estado, comportamiento o rendimiento
• 4 tipos (Prometheus): Counter (solo sube), Gauge (sube/baja), Histogram (buckets acumulativos), Summary (cuantiles en cliente)
• Golden signals: Latencia, Tráfico, Errores, Saturación
• Cardinalidad: Cuidado con etiquetas de alta cardinalidad
• Prometheus: Proyecto graduado de CNCF, ampliamente adoptado

Próximos pasos:

Para principiantes:

1. Comprende los 4 tipos de métricas
2. Implementa golden signals en tu aplicación
3. Usa Prometheus para exposición

Para equipos de operaciones:

1. Configura SLOs basados en SLIs
2. Monitorea la cardinalidad de tus métricas
3. Integra con Real-Time Metrics para dashboards

Para empresas maduras:

1. Optimiza consultas PromQL
2. Implementa alertas basadas en SLOs
3. Usa histogramas para SLIs de latencia

¿Quieres visualizar métricas en tiempo real con latencia de segundos? Descubre Real-Time Metrics y Data Stream para recolección y análisis de métricas a escala. Comienza gratis.