Observabilidad en lenguaje de negocio
La primera herramienta que construí con IA salió del cansancio de enterarnos de las fallas por los clientes.
Lo que dice el log
WARN payments-worker · no events processed in 00:47:12
Lo que lee el equipo
Los pagos dejaron de procesarse hace 47 minutos
No hay errores. El proceso se detuvo.
Qué hacer Revisar el proceso de pagos antes de que lleguen los reclamos.
Lo que dice el log
ERROR mail-gateway · 550 5.1.1 recipient address rejected
Lo que lee el equipo
Un cliente no recibió su comprobante
La dirección de correo que dejó no existe.
Qué hacer Soporte puede corregir el correo y reenviarlo.
Siguiendo el caso 48213
Pedido recibido
Pago aprobado
Factura emitida
Despacho detenido hace dos horas
Qué hacer Avisar a logística. El cliente todavía no reclama.
Empiezo esta bitácora con la primera herramienta que construí con IA, porque de ahí salió casi todo lo demás. La hice por cansancio, sin un plan.
Casi todas las empresas de software pagan una plataforma de observabilidad. Sus servicios escriben millones de líneas de log al día, todo queda guardado y hay un panel con gráficos. Aun así, cuando algo se cae, muchas veces el primero en enterarse es un cliente, o soporte cuando empiezan a llegar los reclamos. Me ha pasado muchas veces, y siempre la información estaba ahí y nadie la vio a tiempo.
Datos hay de sobra. El problema es que están escritos en un lenguaje que pocos en el equipo entienden, y son tantos que nadie alcanza a leerlos.
Logs que pocos entienden
Para quien construyó el servicio, un log como «Queue full (max 50), rejecting publish to orders.confirm» lo explica todo. Para alguien de soporte, de producto o para quien dirige el área no dice nada, y son ellos los que necesitan saber rápido si hay un cliente afectado. Así, la operación queda en manos de unas pocas personas, y cuando no están, nadie sabe bien qué pasa.
Además, las fallas más caras suelen ser las que no dejan rastro. Un proceso que se detiene no registra errores, solo deja de escribir. Una integración que falla y responde «todo bien» tampoco activa ninguna alarma. Las herramientas que buscan errores no encuentran nada, y el problema se descubre cuando ya causó daño.
Si se intenta resolver con alertas, pasa lo contrario. Se avisa de todo, el equipo se satura y a las dos semanas nadie mira el canal. El sistema parece cubierto, pero no lo está.
Lo que hace monitor-log
monitor-log lee los logs que la empresa ya tiene, sin copiarlos ni guardarlos, y los traduce a lo que significan para el negocio: qué pasó, a quién afecta y qué hay que hacer.
Lo que dice el log
2026-08-20T14:02:11Z ERROR orders-api
[a3f9c2] Queue full (max 50), rejecting
publish to orders.confirm
Lo que lee el equipo
Los pedidos se están encolando
Quien compra queda esperando la confirmación y no recibe nada.
Qué hacer Revisar el consumidor de la cola de confirmación: llegó a su tope y está rechazando.
La traducción la escribe quien conoce el negocio, en un diccionario que se edita en pantalla y se prueba con líneas reales antes de guardarlo. Así, cualquier persona del equipo puede abrir el panel y entender el estado de los servicios sin pedir ayuda.
Con el uso me di cuenta de que lo más útil eran otras tres funciones:
- Prioriza. De las miles de líneas críticas del día, dice cuáles hay que atender hoy y por qué.
- Avisa cuando un flujo se detiene. Cada flujo aprende su ritmo normal y avisa si se para, aunque no haya registrado ningún error.
- Sigue un caso. Con un número de pedido o de factura, muestra todo su recorrido por los servicios, que es lo que necesita soporte cuando un cliente pregunta qué pasó con lo suyo.
Lo que cambia para un equipo
Los problemas aparecen en el panel apenas ocurren y se resuelven antes de llegar como reclamo. Y un diagnóstico que antes necesitaba a alguien capaz de leer logs lo puede hacer cualquiera del equipo.
La operación también deja de depender de unos pocos. Cuando lo que significa cada falla queda escrito en un diccionario compartido, ya no lo sabe solo quien lleva más años en la empresa, y esa persona puede tomarse vacaciones tranquila.
El panel, además, dice lo que no sabe: qué líneas no pudo explicar y qué servicios no dieron señales. Eso sirve más que un panel con todo en verde. Y como funciona sobre la plataforma que la empresa ya paga, no hay que reemplazarla ni duplicar sus datos.
Sus límites
monitor-log no reemplaza a las personas que operan los servicios ni a la plataforma de observabilidad. Las reglas de traducción las escribe y las valida el equipo, y si una regla no está probada, el panel lo avisa.
Sirve para que más gente vea lo que ya está en los logs, y para que nadie se entere por un cliente de algo que los logs ya decían. Si quieres probarlo con tu equipo, está en monitor-log.com.
Construirlo me enseñó algo que usé en todo lo que vino después: lo que no queda escrito depende de una persona, y esa persona se cansa. Con la IA pasaba lo mismo, porque cada uno la usaba a su manera y lo que aprendía se perdía al cerrar la conversación. Las próximas entradas cuentan lo que hice para cambiar eso, y lo solitario que puede ser ese papel.