Bitácoras, Trazas, Logs, Logging

Una consabida forma de ver que sucede con tus programas es "pintar" los valores de tus variables. Esta rústica forma de depurar también tiene otra acepción: loggear :S

¿Quién dijo que poner System.out.println (javeros) o Console.WriteLine (.net) por cada línea es manejar una bitácora? No lo sé, pero en los ambientes java (que es lo que tengo más cercano) tenemos mega-archivos log de cientos de megabytes generados con poderosos System.out.println statements. Logging is cool!

Pero, eso no es logging. En casi cada aplicación "grande" o "empresarial" (lo que sea que significa esto) se incluye algún mecanismo de bitácoras. Agregar sentencias de rastreo es un mecanismo de "bajo nivel" para depurar código. Puede ser que sea la única opción por no existir un depurador para la plataforma o por que ya se trata de un ambiente multitarea/multihilos.

En el caso de una aplicación ejecutándose en un ambiente de producción, tampoco se puede hacer uso de herramientas de desarrollo o depuración. Casos así requieren que se le otorgue a los administradores u operadores herramientas que les permitan monitorear el comportamiento de los sistemas.

Para hablar de logging se requiere cumplir una serie de requisitos. Uno de ellos son los "contextos", entidades que contienen la información precisa de la ejecución de la aplicación. También se requiere distinguir diferentes niveles de severidad, desde el error fatal hasta mensajes de depuración; estas características deben poder configurarse fuera del código de la aplicación, es decir, en los programas incluimos todas las llamadas de rastreo que consideremos pero dependiendo de la configuración se van ir grabando las seleccionadas.

También tiene sus desventajas. El registro de entradas en archivos o bases de datos consume tiempo de procesador, llamadas a dispositivos que finalmente se ve como un cierto grado de lentitud en la aplicación. Si se registran demasiadas entradas, el log se torna ilegible. Si se filtran demasiados niveles de severidad, puede ser que se pierdan elementos que podrían auxiliar a resolver problemas.

Como ya es costumbre, el mundo java ha pasado por esto antes y gracias a la colaboración de muchas personas se construyó un framework para este tipo de necesidades. Ha sido tal el éxito de esta iniciativa que se desarrollaron componentes similares para otras plataformas y lenguajes (C++/PHP/Ruby) e incluso se incluye en algunos productos comerciales, BEA WebLogic Server por ejemplo (aunque ninguno de los programadores que conozco lo usan, siguen con sus pinchis println's) y obvio, también se construyo para .NET.

En este caso, log4net respeta todos los principios de su ancestro log4j y tenemos archivos de configuración, contextos, jerarquía de loggers e implementaciones de "appenders" que nos permiten tener diferentes destinos para nuestros logs. Ahora si, "logs".

El primer ejercicio de muestra del uso de log4net lo pueden encontrar en mi repositorio de ideas Google Code. Mediante subversion pueden obtener una copia de trabajo y trastear un rato con él.

Finito.