Analizar logs

El problema de la aguja en el pajar

Los logs de una aplicación se escriben para ser completos, no legibles durante un incidente: una solicitud sana y una a punto de tumbar el flujo de pago se registran con el mismo nivel de detalle, entrelazadas entre cien conexiones simultáneas. Los ingenieros de guardia conocen el ritual de buscar 'ERROR' y aun así ahogarse en ruido, porque la señal real suele ser un patrón entre líneas, no una sola línea con esa palabra. El análisis de logs existe para hacer esa detección de forma automática, a la velocidad que un incidente exige.

Qué envía y qué recibe

Envía mediante POST texto crudo de log —líneas planas, logs en JSON, o un formato estructurado común— a /text/log-analyze, con contexto opcional como el nombre del servicio o la ventana de tiempo. La tarea corre de forma asíncrona: el task_id vuelve de inmediato, y el análisis llega a su webhook firmado o a un enlace firmado válido por 24 horas, estructurado como hallazgos agrupados —una firma de error repetida, un pico inusual, una secuencia que precede fallos conocidos— con las líneas que lo respaldan.

Cómo separa la señal del ruido

Busca repetición, secuencia y desviación respecto a los patrones normales del propio log, en vez de comparar contra una lista fija de cadenas de error conocidas, y eso le permite detectar un modo de fallo nuevo que nunca había visto. Es el instinto que desarrolla un SRE con experiencia tras suficientes postmortems —notar que una ráfaga de timeouts en un servicio precede a un fallo en cascada en otro— convertido en algo que lee un log con el mismo cuidado cada vez, sin el cansancio de hacerlo a las 3am por décima vez en el trimestre.

Cómo encaja en un flujo de incidentes

Al ser asíncrono y cobrarse por volumen de líneas, funciona igual de bien disparado automáticamente por una alerta (enviar la última hora de logs en cuanto la tasa de error se dispara) que invocado a mano en medio de un incidente para darle sentido a un volcado recién pegado en un canal. El webhook puede alimentar su herramienta de respuesta a incidentes, convirtiendo el análisis en el primer comentario del ticket antes de que alguien termine de leer la alerta.

Lo que no le va a decir

Saca a la luz lo anormal en los logs; no tiene acceso a su historial de despliegues ni al contexto de negocio, así que un hallazgo como 'la tasa de error de /checkout subió 40 veces a las 14:02' es el punto de partida de su investigación, no la conclusión de la causa raíz. Ese enfoque es intencional: el trabajo de la herramienta es ahorrarle leer cincuenta mil líneas, no reemplazar al ingeniero que sabe qué cambió.