Hay una diferencia importante entre monitorear y observar. El monitoreo responde a la pregunta "¿está funcionando?". La observabilidad responde a "¿por qué se comporta así?", y para eso necesita datos que se puedan interrogar: métricas, logs y trazas.
• La pregunta clave •
Los KPIs de observabilidad son los indicadores que resumen ese conjunto de datos en algo accionable. No son gráficos para mirar: son números que deberían gatillar decisiones. Si un KPI sube o baja y nadie hace nada distinto, ese KPI no está sirviendo para lo que fue creado.
Estos cuatro miden la capacidad de reacción de tu equipo. Son los que más rápido revelan si el problema está en la detección, en la comunicación o en la resolución. Los KPIs de observabilidad son los indicadores que resumen ese conjunto de datos en algo accionable. No son gráficos para mirar: son números que deberían gatillar decisiones. Si un KPI sube o baja y nadie hace nada distinto, ese KPI no está sirviendo para lo que fue creado.
Cuánto tarda tu sistema en darse cuenta de que algo anda mal, desde que el problema empieza hasta que se genera la alerta.
Un MTTD alto significa que estás enterándote de las fallas por tus usuarios y no por tus herramientas. Suele apuntar a cobertura insuficiente de monitoreo o a umbrales mal calibrados.
Cuánto tarda una persona en tomar la alerta desde que se generó.
Un MTTA alto es un problema de proceso. Significa que la alerta se generó correctamente pero nadie la vio, o llegó por un canal que nadie estaba mirando. Es especialmente revelador si lo segmentas por horario: si tu MTTA nocturno es cinco veces el diurno, tienes un problema de notificación, no de monitoreo.
Cuánto tarda el equipo en dejar el servicio operativo desde que reconoció el incidente. Es el KPI que más se cita y también el que más se malinterpreta, porque un MTTR bajo con un MTTA alto sigue siendo una mala experiencia para el usuario: el tiempo total de indisponibilidad es la suma de los tres.
El porcentaje de tiempo en que el servicio estuvo operativo dentro de un período. Conviene traducirlo a minutos para que el número signifique algo real: un 99,9% mensual permite cerca de 43 minutos de caída; un 99,99% permite poco más de 4.
Este marco, popularizado por la práctica de SRE, define qué observar en cualquier servicio antes de sumar métricas más específicas.
Cuánto demora en responder una solicitud. Conviene medirla separando las respuestas exitosas de las fallidas, porque un error rápido puede maquillar el promedio.
Cuánta demanda está recibiendo el sistema. Es el contexto sin el cual las otras tres métricas no se interpretan bien.
Qué proporción de solicitudes falla. Incluye tanto los errores explícitos como las respuestas que llegan correctas pero fuera del tiempo aceptable.
Qué tan cerca del límite está el recurso más restringido del sistema. Es la única de las cuatro que permite anticipar una falla en lugar de constatarla.
Los tres conceptos que traducen las métricas técnicas en un compromiso con el negocio.
Es la métrica concreta que mides: por ejemplo, el porcentaje de solicitudes que responden en menos de 300 ms.
Es el objetivo que te propones para ese indicador: por ejemplo, que ese porcentaje sea al menos 99,5% en un mes.
Es lo que queda entre el SLO y la perfección. Si tu objetivo es 99,5%, tienes un 0,5% de margen para fallar. Ese margen es una herramienta de decisión: mientras te quede presupuesto, el equipo puede seguir desplegando cambios; cuando se agota, la prioridad se mueve hacia estabilidad. Convierte una discusión subjetiva sobre riesgo en una regla operativa.
La Guía de KPIs de observabilidad profundiza en cada indicador con fórmulas de cálculo, valores de referencia por tipo de industria, plantillas para definir tus SLO y un checklist para auditar tu esquema actual de métricas.
El monitoreo verifica condiciones que definiste de antemano y te avisa cuando se cumplen. La observabilidad te permite investigar comportamientos que no anticipaste, combinando métricas, logs y trazas. En términos prácticos: el monitoreo responde preguntas conocidas, la observabilidad te deja hacer preguntas nuevas.
Si tuvieras que elegir solo cuatro, serían MTTD, MTTA, MTTR y disponibilidad, porque cubren el ciclo completo de un incidente. A partir de ahí, las cuatro señales doradas (latencia, tráfico, errores y saturación) describen la salud de cada servicio, y los SLO conectan todo con el compromiso hacia el negocio.
El MTTA mide cuánto tarda alguien en reconocer que existe un incidente; el MTTR mide cuánto tarda en resolverlo una vez reconocido. Son problemas distintos: un MTTA alto suele indicar fallas en la notificación o el escalamiento, mientras que un MTTR alto apunta a diagnóstico o a falta de procedimientos. Mejorar uno no mejora el otro.
No existe un número universal, porque depende del tipo de servicio y del impacto de su caída. Lo útil no es compararte con un valor de referencia externo, sino medir tu propia tendencia y segmentarla: por criticidad del servicio, por horario y por tipo de incidente. Un MTTR estable con incidentes cada vez menos frecuentes es mejor señal que un MTTR bajo con incidentes recurrentes.
Parte por identificar qué experiencia importa realmente al usuario de ese servicio, elige un SLI que la represente, y fija un objetivo que sea alcanzable con tu arquitectura actual. Un error frecuente es apuntar a 99,99% en servicios donde nadie lo necesita: cada nueve adicional multiplica el costo, y un objetivo que se incumple todos los meses deja de funcionar como referencia.
Los KPIs de incidentes conviene revisarlos mensualmente para ver tendencias, y después de cada incidente relevante durante el postmortem. Los SLO se revisan de forma continua a través del consumo del presupuesto de error, no en una reunión periódica.
Las herramientas de monitoreo y APM entregan la mayoría de los datos técnicos. Sin embargo, los KPIs de respuesta (MTTA y MTTR en particular) requieren registrar el ciclo de vida del incidente: cuándo se notificó, quién lo reconoció, cuándo se cerró. Eso normalmente vive en la capa de gestión de incidentes, no en la de monitoreo.
