Métricas y Monitoreo
Tipos de métricas, métodos RED y USE, Prometheus, Grafana y cómo medir el comportamiento de sistemas distribuidos.
¿Qué son las métricas?
Las métricas son valores numéricos que representan el estado o comportamiento de un sistema en un momento dado. A diferencia de los logs (que capturan eventos individuales), las métricas capturan tendencias y permiten responder preguntas como: “¿Cuántas requests por segundo estamos procesando?” o “¿Cuál es la latencia del percentil 99?”
Tipos de métricas
Counters (contadores)
Un counter es un valor que solo puede incrementarse. Se reinicia cuando el servicio se reinicia.
- Uso: Contar eventos acumulativos.
- Ejemplos: Total de requests recibidas, total de errores, total de mensajes procesados.
- Clave: Lo útil no es el valor absoluto sino la tasa de cambio (requests/segundo).
Gauges (indicadores)
Un gauge es un valor que puede subir y bajar. Representa el estado actual de algo.
- Uso: Medir valores instantáneos.
- Ejemplos: Conexiones activas, uso de memoria, tamaño de cola, temperatura de CPU.
- Clave: Útil para detectar saturación y tendencias.
Histograms (histogramas)
Un histograma agrupa observaciones en buckets predefinidos y calcula distribuciones.
- Uso: Medir distribuciones de valores, especialmente latencias.
- Ejemplos: Latencia de requests (p50, p95, p99), tamaño de payloads.
- Clave: Los percentiles son más útiles que los promedios — un promedio de 100ms puede esconder que el 1% de los requests tarda 5 segundos.
Summaries (resúmenes)
Similar a los histogramas pero calculan los percentiles en el cliente en lugar del servidor.
- Uso: Cuando necesitás percentiles exactos sin configurar buckets.
- Trade-off: No se pueden agregar entre instancias, a diferencia de los histogramas.
Métodos para elegir métricas
Método RED (para servicios)
El método RED se enfoca en métricas orientadas al usuario para servicios request-driven:
| Métrica | Qué mide | Ejemplo |
|---|---|---|
| Rate | Requests por segundo | 500 req/s |
| Errors | Tasa de errores | 0.5% de requests con error |
| Duration | Latencia de las requests | p99 = 200ms |
RED es ideal para microservicios que atienden requests HTTP o gRPC. Si estas tres métricas están bien, el servicio probablemente está sano.
Método USE (para recursos)
El método USE se enfoca en la infraestructura y recursos del sistema:
| Métrica | Qué mide | Ejemplo |
|---|---|---|
| Utilization | Porcentaje de uso del recurso | CPU al 75% |
| Saturation | Trabajo en cola esperando | 50 requests en cola |
| Errors | Errores del recurso | 3 errores de disco/hora |
USE es ideal para diagnosticar problemas de infraestructura: CPU, memoria, disco, red, conexiones a base de datos.
Combinando RED y USE
En la práctica, usá ambos métodos:
- RED para entender la experiencia del usuario y la salud de los servicios.
- USE para entender la salud de la infraestructura subyacente.
Prometheus
Prometheus es el estándar de facto para métricas en arquitecturas cloud-native.
Modelo pull
A diferencia de otros sistemas que reciben métricas (push), Prometheus las recolecta activamente (pull). Cada servicio expone un endpoint /metrics que Prometheus consulta periódicamente.
Formato de métricas
# HELP http_requests_total Total de requests HTTP recibidas
# TYPE http_requests_total counter
http_requests_total{method="GET",path="/api/orders",status="200"} 15234
http_requests_total{method="POST",path="/api/orders",status="201"} 3421
http_requests_total{method="POST",path="/api/orders",status="500"} 12
PromQL
Prometheus incluye un lenguaje de consulta poderoso (PromQL) para analizar métricas:
# Tasa de requests por segundo en los últimos 5 minutos
rate(http_requests_total[5m])
# Porcentaje de errores
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# Latencia del percentil 99
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
Alertas con Prometheus
Prometheus se integra con Alertmanager para definir reglas de alerta basadas en PromQL:
groups:
- name: servicio-ordenes
rules:
- alert: AltaTasaDeErrores
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "Alta tasa de errores en el servicio de órdenes"
Grafana
Grafana es la herramienta de visualización más popular para métricas de Prometheus.
Dashboards efectivos
Un buen dashboard de Grafana para un microservicio incluye:
- Panel superior: Métricas RED (rate, errors, duration) como indicadores principales.
- Paneles de latencia: Histogramas con percentiles p50, p95, p99.
- Paneles de recursos: CPU, memoria, conexiones (métricas USE).
- Paneles de dependencias: Latencia y errores hacia servicios downstream.
Variables y templates
Grafana permite crear dashboards dinámicos con variables:
- Selector de servicio para reutilizar el mismo dashboard.
- Selector de rango temporal.
- Filtros por instancia, método HTTP o endpoint.
Buenas prácticas
Nomenclatura consistente
Usá convenciones claras para nombrar métricas:
- Prefijo con el nombre del servicio:
order_service_requests_total. - Sufijo con la unidad:
_seconds,_bytes,_total. - Labels para dimensiones:
method,status,endpoint.
Cardinalidad bajo control
Cada combinación única de labels crea una serie temporal. Evitá labels con alta cardinalidad (como user IDs o request IDs) — pueden hacer explotar el almacenamiento de Prometheus.
Métricas de negocio
No te limites a métricas técnicas. Las métricas de negocio son igual de valiosas:
- Órdenes creadas por minuto.
- Pagos exitosos vs rechazados.
- Tiempo promedio de checkout.
Golden signals
Google define cuatro “golden signals” que todo servicio debería monitorear:
- Latencia: Tiempo que tarda en atender requests.
- Tráfico: Volumen de requests.
- Errores: Tasa de requests fallidas.
- Saturación: Qué tan “lleno” está el servicio.
Resumen
Las métricas son el segundo pilar de la observabilidad. Mientras los logs te dicen qué pasó, las métricas te dicen cómo está el sistema ahora y hacia dónde va. Combinando los métodos RED y USE con herramientas como Prometheus y Grafana, podés construir un sistema de monitoreo que te alerte antes de que los problemas impacten a los usuarios.