← Volver al listado de tecnologías ← Índice de Observabilidad

Métricas — Midiendo lo que Importa

Por: Artiko
metricasprometheushistogramaspercentilesdashboardsobservabilidad

Métricas — Midiendo lo que Importa

¿Qué son las métricas?

Las métricas son mediciones numéricas agregadas sobre el comportamiento del sistema en el tiempo. A diferencia de los logs, que registran eventos discretos con todos sus detalles, las métricas comprimen el comportamiento en números: cuántas veces ocurrió algo, cuánto tiempo tomó, qué porcentaje falló.

Una métrica tiene:

http_requests_total{service="payment", status="200", method="POST"} 1234567 1680617020000

Las métricas son el lenguaje de los dashboards, las alertas y el capacity planning. Son eficientes en almacenamiento (mucho más que logs) y permiten visualizar tendencias a lo largo del tiempo.

Los cuatro tipos fundamentales de métricas

La mayoría de los sistemas de métricas (Prometheus, StatsD, OpenTelemetry) definen cuatro tipos:

1. Counter (Contador)

Un valor que solo puede incrementarse. Nunca decrece. Representa eventos acumulados.

Ejemplos: número total de requests, número total de errores, bytes transmitidos, correos enviados.

http_requests_total{method="POST", status="200"} 1234567
errors_total{service="payment", type="timeout"} 42

Regla clave: Los contadores por sí solos no son útiles — lo útil es la tasa de cambio (rate). “42 errores” no significa nada sin contexto. “42 errores en los últimos 5 minutos, comparado con un promedio de 2” sí.

xychart-beta
    title "Counter: errors_total a lo largo del tiempo"
    x-axis [12:00, 12:05, 12:10, 12:15, 12:20, 12:25]
    y-axis "Errores acumulados" 0 --> 150
    line [2, 5, 8, 12, 85, 130]

2. Gauge (Medidor)

Un valor que puede subir o bajar libremente. Representa el estado actual de algo.

Ejemplos: uso actual de CPU, memoria disponible, número de conexiones activas, temperatura, tamaño de la cola.

system_memory_used_bytes{host="prod-01"} 8589934592
queue_depth{queue="payments"} 234
active_connections{service="api"} 1847

3. Histogram (Histograma)

Registra la distribución de valores observados en rangos (buckets). Es el tipo más poderoso y más incomprendido.

Ejemplos: distribución de tiempos de respuesta, distribución de tamaños de requests, distribución de tiempos de procesamiento.

http_request_duration_seconds_bucket{le="0.005"} 234
http_request_duration_seconds_bucket{le="0.01"}  1234
http_request_duration_seconds_bucket{le="0.025"} 5678
http_request_duration_seconds_bucket{le="0.05"}  8901
http_request_duration_seconds_bucket{le="0.1"}   9876
http_request_duration_seconds_bucket{le="+Inf"}  10000
http_request_duration_seconds_sum  1234.56
http_request_duration_seconds_count 10000

4. Summary (Resumen)

Similar al histograma pero precalcula percentiles en el cliente. Menos flexible pero útil para percentiles muy precisos. Generalmente se prefiere el histograma por ser más agregable.

Por qué los promedios mienten: la importancia de los percentiles

Este es uno de los conceptos más críticos en métricas de performance y uno de los más malentendidos.

Considera este escenario: tienes 100 usuarios. 95 de ellos reciben respuesta en 50ms. Pero 5 usuarios esperan 10,000ms (10 segundos). El promedio es: (95 × 50 + 5 × 10000) / 100 = 547ms.

¿Tu sistema es rápido o lento? El promedio dice “547ms”. La realidad: el 95% de los usuarios tiene una experiencia excelente, pero el 5% tiene una experiencia terrible.

xychart-beta
    title "Distribución de latencias (ms)"
    x-axis ["0-50", "51-100", "101-250", "251-500", "501-1000", "1001-5000", "5001-10000"]
    y-axis "% de requests" 0 --> 100
    bar [95, 0, 0, 0, 0, 0, 5]

Los percentiles revelan esto:

Los percentiles son la herramienta correcta para medir latencia. Los promedios ocultan la cola larga.

La regla de los percentiles en SLOs

En la práctica, la mayoría de los SLOs de latencia se definen como:

¿Por qué p99 y no p100? Porque eliminar el último 1% de requests lentos (edge cases extremos) puede ser prohibitivamente caro. El p99 es el compromiso práctico entre calidad de experiencia y costo.

Cardinalidad: el mayor desafío de las métricas

La cardinalidad es el número de valores únicos posibles para un conjunto de etiquetas. Es el concepto que más frecuentemente destruye sistemas de métricas en producción.

graph TD
    M1["http_requests_total{method, status}"] --> C1["Cardinalidad: 6 × 10 = 60\nMUY MANEJABLE"]
    M2["http_requests_total{method, status, path}"] --> C2["Cardinalidad: 6 × 10 × 1000 = 60,000\nMANEJABLE"]
    M3["http_requests_total{method, status, user_id}"] --> C3["Cardinalidad: 6 × 10 × 10,000,000 = 600M\nDESTRUYE PROMETHEUS"]

Alta cardinalidad significa que tienes muchas series de tiempo únicas. Cada combinación de etiquetas crea una nueva serie de tiempo que debe almacenarse y consultarse.

Etiquetas que NO debes usar en métricas

Etiquetas que SÍ debes usar en métricas

flowchart LR
    BAD["❌ ALTO CARDINALITY\nuser_id: 10M valores únicos\nrequest_id: infinito"] --> |"Usa Logs o Trazas\npara esto"| LOGS[Logs / Trazas]
    GOOD["✅ BAJO CARDINALITY\nstatus: 200/404/500\nmethod: GET/POST\nregion: us/eu/latam"] --> |"Perfecto para"| METRICS[Métricas]

Diseñando métricas de negocio

Las métricas técnicas (CPU, memoria, latencia HTTP) son necesarias pero insuficientes. Las métricas de negocio son las que realmente miden si el sistema está haciendo lo que debe hacer.

El framework de métricas por capas

graph TD
    subgraph "Capa de Negocio"
        B1[Pedidos completados/hora]
        B2[Revenue procesado/min]
        B3[Usuarios activos]
        B4[Tasa de conversión]
    end

    subgraph "Capa de Aplicación"
        A1[Requests/segundo]
        A2[Tasa de errores]
        A3[Latencia p99]
        A4[Eventos procesados]
    end

    subgraph "Capa de Infraestructura"
        I1[CPU / Memoria]
        I2[Disk I/O]
        I3[Network throughput]
        I4[Conexiones DB]
    end

    B1 --> A1
    B2 --> A2
    A1 --> I1
    A2 --> I2

El error más común: Solo monitorear la capa de infraestructura. Puedes tener CPU al 20%, memoria al 30%, latencia de 50ms y aún así tener un servicio completamente roto desde la perspectiva del negocio (por ejemplo, si el servicio de pagos está procesando transacciones pero fallando el 100% de las capturas).

Ejemplos de métricas de negocio

Para un e-commerce:

orders_created_total{status="success"} 
orders_created_total{status="failed"}
revenue_processed_dollars_total
checkout_abandonment_rate
inventory_stock_outs_total

Para un SaaS B2B:

api_requests_total{tenant, endpoint}
feature_usage_total{feature, tier}
trial_conversions_total
subscription_cancellations_total

Dashboards efectivos: principios de diseño

Un dashboard mal diseñado es peor que no tener dashboard — genera confusión, alerta fatiga y fomenta ignorar las señales importantes.

Principios de un buen dashboard

1. La regla del “golden path” primero

El dashboard debe responder la pregunta más importante en 5 segundos. Para un servicio de pagos: “¿Está procesando pagos exitosamente ahora mismo?”

2. Jerarquía de señales

Ordena de lo más crítico a lo más detallado. Arriba: estado general (verde/rojo). Luego: métricas de negocio. Luego: métricas de aplicación. Abajo: infraestructura.

3. Contexto temporal siempre visible

Muestra el tiempo actual, el intervalo de visualización y marcadores de eventos importantes (deploys, incidentes).

4. Comparación con baseline

Una métrica sola no significa nada. “1000 errores/min” puede ser normal o catastrófico. Muestra siempre la comparación con el período anterior (ayer misma hora, semana anterior).

graph LR
    subgraph "Dashboard Bien Diseñado"
        TOP[Estado General\nSemáforo verde/rojo] --> MID1[Métricas de Negocio\nOrders/min, Revenue/min]
        MID1 --> MID2[Métricas de Aplicación\nLatencia p99, Error rate]
        MID2 --> BOT[Infraestructura\nCPU, Memoria, I/O]
    end

Anti-patrones de dashboards

Métricas en el ciclo de un incidente

sequenceDiagram
    participant M as Métricas
    participant A as Alert Manager
    participant OC as On-Call Engineer
    participant D as Dashboard

    M->>A: error_rate > 5% por 5min
    A->>OC: PagerDuty / SMS
    OC->>D: Abre dashboard de servicio
    D->>OC: Muestra: error rate 12%, latencia p99 2.3s
    OC->>D: Navega a: distribución de errores por endpoint
    D->>OC: /api/checkout tiene 89% de los errores
    OC->>D: Navega a: errores de /api/checkout por tipo
    D->>OC: TimeoutException 94% del total
    OC->>D: Cruza con: métrica de latencia del servicio de pagos
    D->>OC: payment-service p99 = 8000ms (normal: 200ms)
    Note over OC: Causa identificada en 4 minutos

Alertas basadas en métricas: principios básicos

Las alertas son la razón principal por la que existen las métricas en operaciones. Pero las alertas mal diseñadas son uno de los mayores problemas en ingeniería de operaciones.

Una alerta efectiva:

Ejemplo de alerta mala:

alert: HighCPU
expr: cpu_usage > 80
for: 5m

Ejemplo de alerta buena:

alert: PaymentServiceErrorBudgetBurning
expr: |
  rate(http_requests_total{service="payment", status=~"5.."}[5m]) /
  rate(http_requests_total{service="payment"}[5m]) > 0.05
for: 5m
annotations:
  summary: "Payment service error rate above 5% SLO"
  dashboard: "https://grafana.example.com/d/payment-service"
  runbook: "https://wiki.example.com/runbooks/payment-service-errors"

Las alertas en detalle se cubren en el capítulo 8.

Herramientas del ecosistema

Recopilación y almacenamiento:

Visualización:

SaaS:

Referencias

← Volver al listado de tecnologías ← Índice de Observabilidad