Los sistemas modernos han incrementado la conexión entre microservicios y APIs y monitorear dichas conexiones pueden llegar a ser un gran reto.
Un log irrelevante es peor que no tener un log, ya que da una falsa sensación de seguridad. Un log con información mínima o poco importante nos hace perder tiempo. Crear y mantener un log implica tiempo, y en ocasiones los plazos apresurados relegan los logs a la sombra y empiezan a descuidarse.
1. Niveles de log
Cuando se tiene un log también se pueden tener niveles, y en este caso "nivel" se refiere al tipo y la cantidad de mensajes registrados en el log.
Nivel de traza (trace)
El nivel de traza registra cada mensaje producido en el sistema, incluyendo información sensible. Definitivamente no queremos esto en producción, pero si en nuestro ambiente de desarrollo, ya que nos permite monitorear el comportamiento de nuestro sistema.
Nivel de depuración (debug)
Este nivel nos permite realizar una "investigación" del comportamiento de la funcionalidad del sistema, es para casos puntuales de depuración, y no valdría mantener registro de este nivel en producción, solo en desarrollo.
Nivel informativo (information)
Registra mensajes que permitan el flujo general de la aplicación, considero que esto si se debería mantener en el log, nos da oportunidad de conocer el camino de cada proceso, lo cual nos permite descartar errores que no pertenecen a un flujo en particular.
Nivel de advertencia (warning)
Estos mensajes registrados nos indicarán un proceso anormal o inesperado, que sin embargo no causarán que la aplicación se detenga.
Nivel de error (error)
Estos son los mensajes cuando el flujo actual de ejecución es detenido debido a un fallo. Se debería indicar en el log el fallo en la actividad actual, no un fallo a nivel de aplicación.
Nivel crítico (critical)
Este log describe un cuelgue o error catastrófico que hace imposible continuar con la ejecución de la aplicación, un mensaje de nivel crítico requiere atención inmediata.
2. Librerías para logs en .NET
El .NET framework cuenta con el ensamblado Microsoft Logging, que cubre las necesidades básicas de logging, y puede ser usado en cualquier tamaño de sistema. Pero como cada sistema es diferente, cada sistema y organización requiere un nivel de detalle y personalización diferente, que el ensamblado nativo no cubre.
Existen las librerías como Serilog, que a este año (2022) es muy popular. Proporciona logs para archivo, consola y muchos otros destinos. Ninguna librería es perfecta o adecuada. Cada uno tiene sus necesidades y gustos, y lo importante es implementar el log y hacerlo de forma que la información registrada sea útil e importante.
3. Mejores prácticas y recomendaciones
Logs estructurados
Los mensajes registrados en el log debe poder filtrarse para poder buscar en ellos. Un log que deba ser revisado línea por línea para encontrar el error, es en sí un error y un agujero por donde se pierde tiempo. Los mensajes deben ser tipo plantilla.
En producción solo deben estar habilitados los logs apropiados
Antes de publicar la aplicación en producción, se debe analizar la verdadera necesidad de cada nivel de log. Un log con demasiada información es igual a un log con poca información. Los logs de nivel traza y depuración deben estar deshabilitados en producción.
Usar una librería de terceros
No hay que reinventar la rueda. No gastemos tiempo y recursos para recrear una funcionalidad completa de logs, cuando ya existen librerías gratuitas y de pago. Y sobre eso, verificar que la librería que se está usando pueda ser utilizada en producción, y no estar en problemas cuando nos demos cuenta que estamos usando una versión limitada o pirata.
Información sensible
En logs de producción no se debe registrar información sensible o privada. Información del usuario como contraseñas, números de tarjeta de crédito o cualquier dato que no deba ser público, no debe ser registrada en el log. Un log no necesariamente está encriptada, y si llega a exponerse públicamente, sería un gran fallo de seguridad.
Mensajes de log relevantes
Un mensaje de log registrado en el log no significa que el sistema está preparado para ser analizado, porque el mensaje podría no tener mucho sentido.
Entonces, cuando registres algo en el log, piensa que información será relevante para un futuro análisis de la ejecución. Por ejemplo, en un bloque de excepción, el mensaje o aún mejor, toda la excepción debe ser registrada en el log. Y el método donde se está registrando el mensaje, debemos tener su nombre.
4. Conclusión
Aunque gran parte de este artículo se refiere a buenas prácticas para escribir logs eficientes en nuestras aplicaciones, estos consejos no deben considerarse reglas absolutas. Cada organización o sistema tienen diferentes contextos y hay que ser flexibles en la aplicación de estos consejos.
0 Comentarios