Definición
La observabilidad es la capacidad de entender qué está pasando dentro de un sistema desde fuera, con la información que ya emite.
La diferencia con monitorizar es sutil y práctica:
- Monitorizar responde preguntas que preparaste de antemano: ¿está caído? ¿la CPU pasa del 80 %?
- Observabilidad te permite responder preguntas que no habías previsto: ¿por qué justo ese cliente ve la web lenta solo por las mañanas?
Un sistema es observable si puedes investigar un problema nuevo sin tener que desplegar código para averiguar qué pasa. Y esa es la prueba honesta: si cada vez que algo falla tu primer paso es añadir logs y volver a desplegar, tu sistema no es observable.
Los tres pilares
Logs. El diario de lo que ocurrió: eventos concretos con su momento. Sirven para reconstruir la historia de un caso.
Métricas. Números agregados a lo largo del tiempo: peticiones por minuto, tiempo de respuesta, errores por hora. Sirven para ver tendencias y para disparar alarmas.
Trazas. El recorrido completo de una petición atravesando el sistema, con cuánto tardó en cada paso. Sirven para saber dónde se fue el tiempo cuando hay varias piezas implicadas.
La regla para elegir: las métricas te dicen que algo va mal, las trazas dónde, y los logs por qué.
Cómo escribir logs que sirvan
Casi todos los logs que se escriben no sirven, y siempre por los mismos motivos.
Con contexto, no sueltos. «Error al guardar» es inútil. «Error al guardar pedido 4471 del cliente 88: columna importe nula» se arregla sin investigar.
Estructurados. Si cada línea es una frase libre, buscar entre miles es imposible. En formato clave-valor o JSON se pueden filtrar.
Con un identificador que cruce todo. Un mismo id de petición en todas las líneas relacionadas permite ver el caso completo. Sin eso, tienes piezas sueltas.
Con niveles de verdad. Si todo es ERROR, nada lo es. ERROR para lo que exige actuar, WARN para lo raro que se toleró, INFO para hitos, DEBUG para el detalle que normalmente está apagado.
Sin datos personales ni secretos. Los logs se copian, se comparten y se guardan mucho tiempo. Una contraseña o un DNI en un log es una filtración esperando su momento.
Ejemplo práctico
En un sistema de gestión pequeño, la observabilidad no exige herramientas caras. Exige decidir qué quieres poder responder.
Las tres preguntas que más veces he necesitado contestar deprisa:
- ¿Esto que dice el usuario que pasó, pasó de verdad? Se responde con un log por operación que cambie datos, con quién, qué y cuándo.
- ¿Desde cuándo está roto? Se responde con la marca de última ejecución con éxito de cada proceso automático. Ver tarea programada.
- ¿Va lento o me lo parece? Se responde con el tiempo de respuesta guardado, aunque sea de forma tosca.
Lo que aprendí: el momento de instrumentar es antes de que ocurra el problema, y eso choca con la intuición de que instrumentar es trabajo que no aporta. Aporta el día que un cliente asegura que hizo un pedido y el sistema dice que no: con registro, se resuelve en dos minutos y con certeza; sin él, es tu palabra contra la suya.
Y la trampa opuesta, en la que también he caído: registrar todo. Un sistema que escribe cientos de miles de líneas al día es tan opaco como uno que no escribe ninguna, con el añadido de que llena el disco. Si nadie va a leer una línea nunca, y no sirve para agregar una métrica, no debería escribirse.
El equilibrio que funciona: todo lo que cambie datos o dinero se registra; lo que solo lee, no.
Errores comunes
- Añadir logs solo cuando algo falla, y quitarlos después.
- Logs sin contexto. Un «error» sin el qué ni el cuál no ahorra nada.
- Todo al mismo nivel.
- Datos personales o secretos dentro de los logs.
- No rotarlos. Llenan el disco y tiran el servidor — un fallo causado por el propio sistema de diagnóstico.
- Alarmas que saltan constantemente. Una alarma que se ignora por costumbre es peor que no tenerla.
- Confundir «tengo logs» con «soy observable». Si no puedes buscarlos ni cruzarlos, son un fichero grande.
Cuándo montarlo
Desde el principio, y de forma proporcionada: en un sistema pequeño bastan logs estructurados con identificador de petición, la marca de última ejecución de cada proceso automático y una alarma por ausencia de señal.
La pregunta que mide si lo tienes: cuando algo falle mañana, ¿podré averiguar por qué sin tocar el código? Si la respuesta es no, ahí está el trabajo pendiente.
