La diferencia entre monitorización y observabilidad en sistemas distribuidos

La monitorización clásica se basa en preguntas conocidas de antemano: si el servidor está activo, si la CPU supera el 80 por ciento, si el disco se está llenando, si terminó el proceso nocturno. Un operador elige una señal, fija un umbral y genera una alerta cuando se supera. Para un número reducido de servidores que ejecutan un monolito, esto funciona bien, porque la lista de cosas que pueden fallar es corta y las personas de guardia la conocen de memoria.

La limitación es que cada comprobación encierra una predicción. Cuando el fallo es uno que nadie previó, como una dependencia posterior lenta, una tormenta de reintentos o una caché que técnicamente funciona pero devuelve datos obsoletos, los paneles siguen en verde mientras los clientes se quejan. La monitorización sigue siendo necesaria, pero deja de ser suficiente cuando el sistema supera el modelo mental de una sola persona.

Si se traslada la misma función de negocio a una docena de servicios con una cola de mensajes en medio, cambian tres cosas. Primero, una sola solicitud de usuario pasa ahora por muchos procesos en muchos hosts, de modo que ningún archivo de log cuenta toda la historia. Segundo, los fallos se vuelven parciales: una región, un inquilino o una ruta de código va lenta mientras el conjunto parece sano. Tercero, el sistema cambia muchas veces al día, de modo que la referencia de ayer ya no sirve.

La observabilidad es la capacidad de comprender el estado interno del sistema a partir de los datos que emite, sin desplegar código nuevo para plantear una nueva pregunta. En la práctica, significa recopilar telemetría rica y de alta cardinalidad (qué cliente, qué endpoint, qué versión, qué región) y poder segmentarla a demanda. La pregunta deja de ser si el sistema está activo y pasa a ser qué usuarios sufren lentitud, desde cuándo y qué cambió.

Un objetivo de nivel de servicio (SLO) es una meta para una medida que perciben los usuarios: por ejemplo, que el 99.9 por ciento de las solicitudes de pago se completen correctamente en menos de 500 milisegundos, medido durante 30 días. El porcentaje y el periodo los fija la organización; lo importante es que el SLO describe lo que experimentan los usuarios y no lo que informa un host.

Un SLO define un presupuesto de errores, la cantidad de fallos que puede absorberse en el periodo, y con él un modelo de alertas distinto. En lugar de avisar cuando la CPU supera un límite, el equipo avisa cuando el presupuesto se consume demasiado rápido para durar todo el periodo (una alerta por tasa de consumo). Los consumos lentos se convierten en tickets para el siguiente día hábil; los rápidos avisan al ingeniero de guardia. Este único cambio elimina la mayoría de las alertas que se disparan sin que nadie tenga que actuar.

Los SLO también dan a ingeniería y al negocio un lenguaje común. Si el presupuesto está sano, el equipo puede publicar más rápido; si se está agotando, el equipo invierte en fiabilidad. Un gráfico de CPU no puede sostener esa conversación.

El fallo más común de los programas de monitorización es el exceso de alertas, no su escasez. Cuando una rotación recibe decenas de avisos por semana y la mayoría no requiere ninguna acción, las personas dejan de leerlos, y el que importa se pierde entre el ruido. Cada alerta debería superar una prueba sencilla: una persona debe poder hacer algo al respecto de inmediato. Si no es así, su lugar es un panel o un informe diario, no un aviso.

Trate el conjunto de alertas como código sujeto a revisión. Cada alerta tiene un responsable, un enlace a su runbook y una razón de ser; las alertas que se disparan sin ninguna acción durante un mes se eliminan o se degradan. Mida la propia rotación: avisos por semana, avisos fuera del horario laboral, tiempo hasta la confirmación. Una rotación de guardias sana es señal de un sistema sano, y una que no lo es indica con claridad dónde invertir.

Los sistemas distribuidos añaden un requisito más: las alertas deben aportar contexto. Un aviso que dice “error rate high on payments-api” es una tarea de investigación; un aviso que enlaza con el SLO afectado, el último despliegue y el endpoint con más fallos es una decisión.

Los datos de observabilidad tienen un costo, y la factura suele llegar cuando el hábito ya está formado. Los dos factores son el volumen (bytes de logs y spans por solicitud, multiplicados por el tráfico) y la cardinalidad (el número de combinaciones distintas de etiquetas en una métrica). Una métrica etiquetada con el ID de usuario o el ID de solicitud genera una nueva serie temporal por cada valor y desborda cualquier almacén de métricas.

Unos valores predeterminados razonables marcan una gran diferencia. Mantenga los identificadores de alta cardinalidad en las trazas y en los logs estructurados, no en las etiquetas de las métricas. Aplique muestreo a las trazas: conserve todos los errores y las solicitudes lentas, y solo una fracción de las normales. Defina la retención según la señal: métricas durante un año con resolución reducida, logs durante semanas, trazas durante días, y un nivel de archivo para todo lo que exija el cumplimiento normativo. Revise cada mes cuáles son las fuentes que generan más volumen de logs; una sola instrucción de depuración detallada en una ruta crítica puede representar una parte considerable de la factura.

El objetivo no es recopilarlo todo, sino poder responder con rapidez a la próxima pregunta imprevista, a un costo que la organización esté dispuesta a seguir pagando.