Monitoreo vs. Observabilidad
Monitoreo vs. Observabilidad
La confusión más común del campo
Si preguntas a diez ingenieros de operaciones qué es observabilidad, probablemente siete te dirán que es “monitoreo avanzado” o “tener muchas métricas”. Esta confusión es comprensible — ambos conceptos comparten herramientas y objetivos superficiales — pero la distinción es profunda y tiene consecuencias prácticas enormes.
Entender la diferencia no es un ejercicio académico. Es lo que separa a un equipo que pasa sus noches apagando incendios de un equipo que entiende sus sistemas y puede prevenirlos.
¿Qué es el monitoreo?
El monitoreo es la práctica de recopilar y visualizar métricas predefinidas sobre el comportamiento de un sistema, y generar alertas cuando esas métricas superan umbrales establecidos.
El monitoreo responde preguntas como:
- ¿El CPU supera el 90%?
- ¿La latencia promedio superó los 500ms?
- ¿El endpoint
/healthdevuelve 200? - ¿Hay menos de X pods corriendo?
Es fundamentalmente reactivo a lo conocido. Para que el monitoreo funcione, debes saber de antemano qué quieres monitorear y qué valores son problemáticos. Es un sistema cerrado: defines las preguntas, defines los umbrales, defines las acciones.
sequenceDiagram
participant S as Sistema
participant M as Sistema de Monitoreo
participant A as Alerta
participant I as Ingeniero
S->>M: Emite métrica: latencia=600ms
M->>M: Compara con umbral (500ms)
M->>A: Dispara alerta
A->>I: Notificación
I->>S: ¿Qué está pasando?
Note over I: Sin herramientas adicionales,<br/>el ingeniero no sabe la causa¿Qué es la observabilidad en contraste?
La observabilidad es la capacidad de hacer preguntas arbitrarias sobre el comportamiento del sistema en cualquier momento, incluso preguntas que no fueron anticipadas cuando el sistema fue construido.
La observabilidad responde preguntas como:
- ¿Por qué el percentil 99 de latencia está alto solo para usuarios de un proveedor de internet específico?
- ¿Qué comparten todas las requests que están fallando en los últimos 20 minutos?
- ¿En qué punto exacto del flujo de checkout se produce el cuello de botella?
- ¿Qué cambió hace 3 horas que correlaciona con el aumento de errores?
Es exploratoria e investigativa. No requiere que hayas anticipado el problema. Requiere que hayas instrumentado el sistema con suficiente detalle y contexto para poder responder cualquier pregunta.
El problema de las preguntas conocidas
El monitoreo falla en una premisa fundamental: no puedes predecir todos los modos de fallo de un sistema complejo.
Considera un sistema de e-commerce. Puedes monitorear:
- CPU, memoria, disco
- Latencia promedio de los endpoints principales
- Tasa de errores HTTP
- Tamaño de la cola de mensajes
Pero, ¿monitoreaste:
- El tiempo de respuesta del servicio de direcciones de envío por región geográfica?
- La tasa de fallo de validación de códigos de descuento para combinaciones específicas de productos?
- La latencia del servicio de recomendaciones cuando el catálogo supera 1 millón de productos?
- La tasa de éxito de notificaciones push por versión de sistema operativo móvil?
Podrías agregar monitores infinitamente. Y aún así, el próximo incidente probablemente será por algo que no monitoreaste.
graph TD
subgraph Monitoreo Clásico
KP[Known problems<br/>Problemas conocidos] --> A[Alertas configuradas]
A --> R[Respuesta definida]
UP[Unknown problems<br/>Problemas desconocidos] --> ?[¿¿¿???]
end
subgraph Observabilidad
ANY[Cualquier comportamiento\nanormal] --> I[Investigación con\nherramientas ricas]
I --> U[Entendimiento profundo]
U --> FIX[Solución]
endMonitoreo clásico: las cuatro señales doradas
Google introdujo en su libro de SRE el concepto de las cuatro señales doradas — las cuatro métricas más importantes para monitorear cualquier servicio:
quadrantChart
title Las Cuatro Señales Doradas
x-axis Baja Importancia --> Alta Importancia
y-axis Baja Urgencia --> Alta Urgencia
quadrant-1 Crítico
quadrant-2 Importante
quadrant-3 Secundario
quadrant-4 Seguimiento
Latencia: [0.85, 0.75]
Tráfico: [0.65, 0.40]
Errores: [0.90, 0.90]
Saturación: [0.70, 0.65]-
Latencia: El tiempo que tarda el sistema en responder. Importante distinguir entre latencia de requests exitosas vs. fallidas — las fallidas rápidas no son una buena señal.
-
Tráfico: Cuánta demanda recibe el sistema. Para una API: requests por segundo. Para una base de datos: transacciones por segundo. Para un sistema de streaming: mensajes por segundo.
-
Errores: La tasa de requests que fallan. Incluye errores explícitos (HTTP 500) y errores implícitos (HTTP 200 con datos incorrectos).
-
Saturación: Qué tan “lleno” está el sistema. CPU al 95%, memoria al 90%, cola de mensajes creciendo indefinidamente son señales de saturación.
Estas cuatro señales son el punto de partida mínimo del monitoreo. Son necesarias pero insuficientes para la observabilidad.
El modelo RED: otra perspectiva del monitoreo moderno
Complementando las cuatro señales doradas, el modelo RED (propuesto por Tom Wilkie de Grafana) se enfoca en servicios HTTP/RPC:
- Rate: Número de requests por segundo
- Errors: Número de requests que fallan por segundo
- Duration: La distribución del tiempo de respuesta
RED es especialmente útil para microservicios porque es simple y accionable. Tres métricas que dan una imagen rápida de la salud de cualquier servicio.
El modelo USE: para infraestructura
Para recursos de infraestructura (servidores, bases de datos, redes), Brendan Gregg propuso el modelo USE:
- Utilization: ¿Qué porcentaje del tiempo el recurso está ocupado?
- Saturation: ¿Cuánto trabajo extra tiene que esperar en cola?
- Errors: ¿Hay operaciones fallidas?
flowchart LR
subgraph "Servicio (RED)"
R[Rate\nreq/seg]
E[Errors\nerr/seg]
D[Duration\np50/p99]
end
subgraph "Infraestructura (USE)"
U[Utilization\n% uso]
S[Saturation\nqueue depth]
ER[Errors\nerr count]
end
subgraph "Sistema (4 Señales Doradas)"
LAT[Latencia]
TRA[Tráfico]
ERR[Errores]
SAT[Saturación]
endLa evolución: del monitoreo a la observabilidad
La transición de monitoreo a observabilidad no es un salto brusco. Es una evolución gradual que la mayoría de los equipos recorre a medida que sus sistemas crecen en complejidad.
timeline
title Evolución hacia la Observabilidad
2000s : Monitoreo de infraestructura
: Nagios, Zabbix
: Ping checks, CPU, memoria
2010s : Monitoreo de aplicaciones (APM)
: New Relic, AppDynamics
: Métricas de aplicación, transacciones
2015 : Era de microservicios
: Proliferación de servicios
: Necesidad de trazas distribuidas
2018 : Observabilidad moderna
: Logs estructurados, trazas, métricas
: OpenTracing, luego OpenTelemetry
2020s : Observabilidad como estándar
: OpenTelemetry adoption masiva
: High-cardinality analysisSeñales de que tu equipo necesita ir más allá del monitoreo
- Los incidentes tardan más de 30 minutos en diagnosticar
- Frecuentemente dices “no sé por qué pasó esto” después de un incidente
- Para investigar un problema, necesitas SSH a los servidores y grep de logs manualmente
- Tus alertas generan mucho ruido y el equipo las ignora
- Tienes miedo de hacer cambios porque “algo podría fallar y no sabríamos qué”
Diferencias prácticas en el workflow de un incidente
Esta diferencia se hace muy concreta durante un incidente:
Workflow con monitoreo clásico
flowchart TD
A[Alerta: Latencia > 500ms] --> B[Revisar dashboard de métricas]
B --> C{¿La causa es obvia?}
C -->|Sí| D[Fix rápido]
C -->|No| E[SSH a servidores\ngrep logs manualmente]
E --> F[Revisar métricas de infraestructura]
F --> G{¿Encontraste algo?}
G -->|Sí| D
G -->|No| H[Reunión de ingenieros\n¿alguien sabe qué pasó?]
H --> I[Hipótesis + prueba manual]
I --> GWorkflow con observabilidad
flowchart TD
A[Alerta: SLO de latencia en riesgo] --> B[Abrir explorador de trazas]
B --> C[Filtrar requests lentas\npor tiempo y atributos]
C --> D[Identificar servicio o componente\ncon mayor contribución]
D --> E[Ver logs correlacionados\nen el mismo contexto]
E --> F[Identificar causa raíz\nen minutos]
F --> G[Fix o rollback]La diferencia no es solo de velocidad — es de mentalidad. Con observabilidad, el ingeniero on-call tiene confianza. Con monitoreo puro, tiene ansiedad.
¿Hay que elegir entre monitoreo y observabilidad?
No. Son complementarios. El monitoreo sigue siendo necesario para:
- Alertas rápidas cuando algo está claramente mal
- Dashboards de estado del sistema para revisiones rápidas
- Tendencias históricas y capacity planning
La observabilidad es lo que usas para entender por qué la alerta se disparó.
La arquitectura ideal combina ambos:
graph LR
T[Telemetría del Sistema\nLogs + Métricas + Trazas] --> MON[Sistema de Monitoreo\nAlertas y Dashboards]
T --> OBS[Plataforma de Observabilidad\nExploración y Diagnóstico]
MON --> |Alerta: algo está mal| ING[Ingeniero On-Call]
ING --> |Investiga con| OBS
OBS --> |Responde: por qué y cómo| INGEl test de Charity Majors: ¿eres observable?
Charity Majors, co-fundadora de Honeycomb y figura clave en el movimiento de observabilidad, propone una prueba simple:
“Si puedes hacerte una pregunta arbitraria sobre el comportamiento de tu sistema en producción y obtener una respuesta sin necesitar desplegar código nuevo, eres observable.”
Prueba estas preguntas sobre tu sistema actual:
- ¿Cuál es el percentil 99 de latencia para usuarios con más de 100 transacciones previas?
- ¿Cuánto tiempo tarda específicamente la validación de correo electrónico en el registro?
- ¿Qué versión del SDK móvil tienen los usuarios con más errores en los últimos 7 días?
Si no puedes responder estas preguntas hoy, tu sistema no es suficientemente observable.
Resumen
| Característica | Monitoreo | Observabilidad |
|---|---|---|
| Tipo de preguntas | Conocidas de antemano | Cualquier pregunta |
| Modo de operación | Reactivo | Exploratorio |
| Principales herramientas | Métricas + alertas | Logs estructurados + trazas + métricas de alta cardinalidad |
| Cuándo falla | En modos de fallo no anticipados | Cuando el sistema no está instrumentado |
| Objetivo | Detectar problemas | Entender problemas |
En los próximos capítulos profundizamos en cada uno de los tres pilares que hacen posible la observabilidad real.