Si eres un desarrollador backend de cualquier nivel de seniority seguramente que has trabajado con librerías para poder registrar log y traza de los datos que viajan en todos los flujos de tus aplicaciones, APIs, servicios y/o microservicios. Ya sea que hayas trabajado en proyectos empresariales, startups o proyectos propios, es inevitable pensar en interrogantes como las siguientes:

• ¿Cómo puedo seguir la traza de una petición a mi API?
• ¿Cómo puedo ver la respuesta de otra API y/o servicio del cual dependo?
• ¿Cómo puedo detectar si ocurrio un problema no esperado?

Ya sea que programes en leguajes y plataformas como C# .NET, Java u otro tipo de tecnología, es común caer en el sobre registro de información innecesaria y redundante, en la busqueda de poder cubrir las necesidades anteriores.

¿Cómo lograr un buen log sin morir en el intento? La respuesta no es tan obvia, pero se puede resumir con la siguiente frase: “El log también se diseña”.

Al momento de diseñar tu registro de log para cubrir las necesidades anteriores es importante que tengas las siguientes consideraciones:

• Legibilidad de la traza
• Optimización de costos
• Seguridad y privacidad de los datos
• Performance

Analicemos cada punto:

Legebilidad de la traza

Considera definir un formato claro y sencillo para los registros de la aplicación.

En adicional al contexto técnico, considera complementar tus registros con datos de negocio que te den contexto del flujo de la aplicación.

Define con claridad los registros y el detalle que deseas ver en cada ambiente, ya sea el ambiente de desarrollo, calidad, UAT o producción.

Todos las consideraciones mencionadas las puedes lograr con una técnica llamada “Log estructurado”.

Seguridad y privacidad de los datos

La seguridad y privacidad estan relacionados con el manejo de la información confidencial, datos como información de identificación personal (PII), información de medios de pago e información para tener acceso a medios digitales como tokens de acceso y contraseñas. Es decir, el registro de log debe estar diseñado para evitar exponer estos datos sensibles. Para ello ten en cuenta las siguientes consideraciones:

• No incluyas en tu log registro de contraseña y tokens de acceso
• Enmascara datos como nombres, apellidos y cédulas de identificación
• Cifra y encripta datos de medio de pago desde el origen
• Guíate de regulaciones como: Protección de datos personales (GDRP)
• Basate en estandares como OWASP para saber que información puedes y no puedes incluir en tus logs.

Performance

El impacto del performance del registro de log es un punto debatible, sobre todo para ambientes productivos. Sin embargo, dependiendo de donde estes volcando tus logs, la sola operación de persistir el registro va a incurrir en uso de CPU, memoria, disco y red. Puede que subestimes esta operación, pero piensa en un escenario en el cual el equipo de desarrolladores dejaron líneas de “log.info”, “log.debug”, “log.verbose” sin ninguna consideración, súmale a esto la traza dejada por las librerías de las cuales dependes (te sorprenderas) esto multiplicado por los miles o millones de operaciones que soporta tu aplicación. Es por estos motivos que es importante establecer un nivel de log adecuado para tus ambientes, sobre todo para ambientes productivos.

En este punto talvez te estes pregutando en como hacer seguimiento de algún caso de fallo en producción, si no tienes los registros de niveles inferiores. Para no perder capacidad de depuración, diseña tus capas de aplicación de tal manera que te permitan tener contexto de los datos de entrada cuando ocurra un problema no esperado. Puedes valerte de técnicas como “Manejadores globales” e “Interceptores”.

En la siguiente imagen dejo una prueba de comparación en mi lenguaje favorito C#/.NET entre un metodo que registra log de nivel “error” (ConLog) y un metodo con nivel “info” (SinLog) y la configuración de serilog en “Error”. En este resultado se puede ver que el metodo “SinLog” es más veloz que el metodo “ConLog”, en un poco más del 50%, en promedio.

Optimización de costos

Define el destino de tu log para cada ambiente. Por ejemplo para el ambiente de desarollo, calidad y/o UAT, tu log puede ir a un archivo de texto plano simple o un servicio self-host de grafana. Con esto cubriras la necesidad de depuración del equipo de desarollo sin incurrir en costos elevados.

Para un ambiente productivo puedes optar por servicios especializados como los siguientes:

• Servicios de cloud, como Azure Applicatión Insights y Azure Log Analytics
• Servicios especializados como Dynatrace, Datadog ó New Relics

Servicios como los anteriores te permitiran no solo cubrir la necesidad de traza y seguimiento del equipo de desarrollo, sino que te abriran un amplio abanico de posibilidades para poder aprovechar ese log y detectar comportamientos de tu aplicación o servicio que solo pueden ser detectados con el análisis de gran cantidad de registros y data histórica. Ademas estos servicios cuentan con funcionalidades que facilitan enormente el análisis de casos de fallo, hilo de peticiones y subpeticiones, filtro de trazas por nivel de log, etc.

Para que el costo de uso de estos servicios no sea muy alto en el ambiente productivo considera los registros desde niveles tipo WARN y ERROR, de esta manera evitaras estar saturado de registros de nivel VERBOSE, DEBUG o INFO que son muy comunes en librerías de las cuales depende el código.

Si necesitas un plazo de retención largo, puedes llevar los registros más antiguos de log a un storage como Azure Blobs o S3, de esa manera reduciras los costos de almacenamiento por data de muy poco o casi nulo uso. costos de almacenamiento por data de muy poco o casi nulo uso.

En base a todos los puntos descritos, tu log podría tener una figura como la siguiente:

Conclusión

No tomes el registro de logs a la ligera, son un recurso muy importante, no solo para los equipos técnicos, sino también para el negocio.

---

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias

• Logging in C# and .NET