La prueba real de la monitorización no son los dashboards
Cualquier equipo sabe hacer dashboards. La prueba real de un sistema de monitorización son las 3 de la mañana cuando suena el pager: ¿el ingeniero sabe exactamente qué hacer o pasa los primeros 20 minutos buceando en gráficas irrelevantes? Si es lo segundo, tu monitorización es teatro.
Esta guía es un recorrido estructurado por una monitorización que no grita lobo: cuatro señales doradas como base, SLI/SLO/error budgets en claro, reglas de higiene de alertas y una checklist de auditoría para lo que ya tienes.
Esquema
- Las cuatro señales doradas
- SLI, SLO y error budgets sin jerga
- Higiene de alertas — las reglas que protegen a humanos
- Logs vs métricas vs trazas: cuándo usar cuál
- Monitorización sintética y RUM
- Elegir un stack de herramientas
- Una guardia sensata para equipos pequeños
- Checklist de auditoría para monitorización existente
1. Las cuatro señales doradas
Para cada servicio expuesto al usuario, mide primero estas cuatro — y nada más:
- Latencia — tiempo de servir una petición exitosa. p50, p95, p99.
- Tráfico — peticiones por segundo o equivalente de negocio (pedidos/min).
- Errores — peticiones fallidas como tasa, por categoría.
- Saturación — cómo de lleno está el sistema (CPU, RAM, profundidad de cola, pools).
Estas cuatro bien y cubres el 80 % de los incidentes. Añade métricas de infraestructura (disco, red, salud del host) solo cuando realmente predicen impacto de negocio.
2. SLI, SLO y error budgets en claro
- SLI es lo que mides: «% de peticiones bajo 300 ms».
- SLO es el objetivo: «99,5 % bajo 300 ms en 30 días».
- Error budget es lo que tienes permitido gastar: 0,5 % en este caso.
Los error budgets no son castigo. Son el trade-off explícito entre velocidad y fiabilidad. Si quemas el presupuesto del mes congelas features e inviertes en estabilidad — decisión de liderazgo, no drama de ingeniero.
3. Higiene de alertas — reglas que protegen a humanos
- Cada alerta necesita runbook. Si no, es ticket.
- Cada alerta despierta a un humano o va al backlog. No hay tercera categoría.
- Alertas sobre tasa de cambio en lugar de umbrales fijos cuando las baselines son limpias.
- Alertas de síntomas antes que de causas. «El servicio no responde» bate «CPU > 80 %».
- Revisa cada semana las 5 alertas más ruidosas y desactiva o afina tres.
Un equipo paged dos veces por semana con incidentes reales accionables está más sano que uno con 30 pages de ruido.
4. Logs vs métricas vs trazas
| Señal | Mejor para | Peor para |
|---|---|---|
| Métricas | Alerting, SLOs, dashboards | Por qué falló una petición concreta |
| Logs | Forensic, auditoría, debug | Dashboards de alta cardinalidad (coste explota) |
| Trazas | Root cause de latencia entre servicios | Almacenamiento largo plazo barato |
No logues lo que debería ser métrica. No traces lo que debería ser log.
5. Monitorización sintética y RUM
Sintética (checks scripteados desde fuera cada minuto) atrapa caídas y caducidades de cert antes de que el usuario lo note. RUM dice lo que el usuario realmente vive — redes lentas y navegadores viejos que tu staging no tiene.
Ambas. Alerta desde la sintética. Investiga desde RUM.
6. Elegir un stack de herramientas
No hay un único stack correcto. Matriz honesta:
- Prometheus + Grafana + Loki + Tempo — mejor TCO para equipos con un ingeniero que disfruta operándolo. El peor para los que no.
- Zabbix — fuerte en entornos pesados de infraestructura, on-premise, parques mixtos Linux/Windows. Más débil en observabilidad de aplicación.
- Datadog / New Relic / Dynatrace — el time-to-value más rápido, precios altos, lock-in por modelo de datos. A menudo correcto para 20–100 personas que no quieren operar la plataforma.
- Nativo del hyperscaler (CloudWatch, Azure Monitor, GCP Cloud Monitoring) — cómodo, débil entre clouds o cross-on-prem.
Tres criterios: TCO a 3 años (con tiempo de ingeniero), portabilidad de datos, ¿el equipo de guardia quiere usarlo?
7. Una guardia sensata para equipos pequeños
- Mínimo dos ingenieros en guardia. Uno es SPOF humano.
- Primary rota semanalmente. Secondary cubre al primary. Sin héroes 24/7.
- Handover los lunes: incidentes abiertos, alertas más ruidosas, qué arreglar esta semana.
- Política de compensación por escrito.
- Tras cada incidente: postmortem de cinco líneas en docs compartidas. Sin culpas, sobre sistemas.
8. Checklist de auditoría para monitorización existente
- ¿Las cuatro señales doradas están en cada servicio expuesto?
- ¿Cada alerta activa tiene runbook escrito?
- ¿Volumen semanal de alertas vs incidentes que necesitaron humano?
- ¿Cuándo fue el último monitor sintético exitoso de tu flujo más crítico?
- ¿Logs y métricas en el mismo sitio (al menos misma UI)?
- ¿Tu herramienta costará lo que debe en 12 meses al crecimiento previsto?
- ¿La rotación de guardia está documentada, compensada y sin SPOF?
Si no respondes alguna en una frase, ahí empieza el trabajo.
Conclusiones
- Construye sobre las cuatro señales doradas, no sobre trivia de infraestructura.
- Los error budgets son conversación de liderazgo sobre velocidad vs fiabilidad.
- Cada alerta necesita runbook y acción; todo lo demás es ticket.
- Logs, métricas y trazas se complementan — no se sustituyen.
- La elección de herramienta es decisión TCO a 3 años, no checkbox de features.
Si quieres revisión externa de tu monitorización contra esta checklist, ponte en contacto — hablarás con un ingeniero, no con un comercial.