Monitorización de logs durante el desarrollo web

Fecha de publicación: 2022-03-18

Las aplicaciones serias generan muchos logs. ELK, Sentry, Google Cloud Logging y CloudWatch son valiosos para operación en producción, pero el desarrollo tiene otras necesidades. Quien desarrolla necesita feedback inmediato y selectivo mientras cambia una aplicación web, no un archivo operativo a largo plazo.

Una aplicación web distribuida

Las aplicaciones web tienen frontend y backend. El backend puede ser heterogéneo o estar replicado tras balanceo; el frontend existe naturalmente en muchos ordenadores, teléfonos y tabletas. Un agregador para desarrollo debe recoger logs de todas esas fuentes e identificar cada una, para aislar una instancia de navegador o un componente de servidor.

Trazar un proceso de negocio

Una acción de negocio suele cruzar componentes. En un chat, el frontend del remitente envía un mensaje, el backend lo acepta y reenvía, y el frontend de quien recibe lo guarda. La vista útil agrupa esos registros en un único proceso aunque procedan de dispositivos y código diferentes.

En la práctica se necesita un identificador de correlación que viaje con solicitud o evento. Debe poder exponerse sin riesgo en logs, ser suficientemente único durante la retención y añadirse en cada traspaso.

Vincular logs con código

Un registro debe identificar el código que lo produjo, al menos el archivo fuente. A menudo se llega al origen con la búsqueda del IDE. Campos estructurados de módulo, archivo, función y línea —cuando sean fiables— acortan el camino frente a un texto aislado.

Velocidad de feedback

El desarrollo depende del ciclo: cambiar código, ejecutar un escenario, leer feedback y ajustar. Los registros seleccionados deben llegar según se producen, con demora de segundos y no de minutos. Por eso, durante desarrollo un flujo en vivo vale más que una agregación programada.

Retención corta

Los logs de desarrollo envejecen rápido. Tras cambiar código y hacer otra prueba, los anteriores a menudo pierden valor. Conservar aproximadamente la última hora, o un número limitado de entradas recientes, encaja mejor que un archivo costoso y permanente. También reduce la retención accidental de datos sensibles de prueba.

Niveles para desarrollo

El logging operativo suele distinguir DEBUG, INFO, WARN, ERROR y FATAL. Al desarrollar suele ser más útil ver el flujo informativo completo y destacar visualmente los errores. Lo importante es filtrar rápido, no ocultar el contexto que explica un error.

Resumen y prueba de concepto

Un agregador orientado a desarrollo necesita filtrado en tiempo real, vínculo con instancia emisora y archivo fuente, y correlación de proceso. Construí una prueba de concepto, flancer64/pwa_log_agg: un servidor recibe logs por POST y los retransmite a una interfaz de navegador mediante Server-Sent Events (SSE); el filtrado ocurre en cliente.

Demuestra una dirección, no pretende sustituir plataformas de observabilidad. Una versión de producción además definiría autenticación, aislamiento de tenants, esquemas estructurados, redacción, control de retención y fiabilidad de transporte. El proyecto Remote Console de este sitio desarrolla la misma idea de feedback para desarrollo.