Grupo Linuxero del Bajío

La importancia de guardar una bitácora

Víctor Manuel Jáquez Leal

Cuando comenzamos a escribir programas de software y nuestros programas se van complicando, normalmente recurrimos a una técnica que existe desde los albores de la computación: imprimir en pantalla mensajes que nos den una idea de lo que está pasando en el programa.

Posterioremente descubrimos los “debuggers” donde podemos hacer trazas y seguir paso a paso, en tiempo real, la ejecución del programa y consideramos que imprimir esos mensajitos es algo de novatos, enorgulleciéndonos de nuestras nuevas habilidades computacionales.

Pero nuestros programas se van haciendo más y más grandes, más y más complejos, agregamos nuevas tecnologías a nuestro repertorio, como multiprocesos y multihilos, procesamiento distribuido, etc., y nos damos cuenta que someter a una sesión de debugging cada ves que observamos un comportamiento anómalo en nuestro código es más enfadoso y consume mucho tiempo en podar todos los detalles que no nos interesan y enfocarnos en la parte que nos incumbe.

Es cuando llega la iluminación: volver a los mensajitos en pantalla :)

Linux (el kernel) lo hace, el Apache lo hace, XOrg lo hace, ¿por qué nosotros no?

Claro, ya no somos tan ingenuos y sabemos que los mensajitos en pantalla contaminan la observación del comportamiento de la aplicación. Entonces decidimos mandarlos a otra salida, como a un archivo, donde posteriormente, con nuestras habilidades con expresiones regulares, podremos rastrear el mensaje que nos es de utilidad.

Sin embargo, aun mandando a un archivo especial de bitácora todos nuestros mensajes, resulta cada vez más complicado dar con el mensaje que nos indique la falla, además caemos en cuenta de el castigo de procesamiento que incurre cada escritura en dicho archivo, causando una baja en el rendimiento de nuestra aplicación. Ahora somos menos ingenuos.

Decidimos entonces un mecanismo para habilitar o deshabilitar la escritura de mensajes, pero también descubrimos que podemos categorizar los mensajes de error en grupos como DEBUG, LOG, INFO, WARNING, ERROR, etc. Y entonces podemos decirle a nuestra aplicación, tal vez ya hasta en tiempo de ejecución, la categoría que nos interesa registrar: sólo errores si nuestra aplicación está en producción, o el montón de mensajes de debug que son útiles a la hora de rastrear los detalles difíciles.

Es más, luego se nos ocurre que podríamos enviar nuestros mensajes de bitácora por correo automáticamente, o enviarlos a otra computadora con un servicio centralizado de bitácoras, o podriamos mandarlos a otro proceso que haga gráficas y estadísticas, o hasta profundos análisis de patrones.

Llegados a este punto vemos que la implemetación de un subsistema de bitácoras en esencial para todo proyecto realtivamente grande, y llegamos a la conclusión que tener que rehacerlo cada vez que comenzamos un nuevo proyecto es totalmente estúpido. Ya no somos tan ingenuos. Debe de haber un sistema de bitácoras, y además una biblioteca para el manejo de los mismos.

Lo más cercano a nosotros es el syslog. Syslog es un servicio que prácticamente todos los Unixes lo implementan y lo usan. Las aplicaciones, a través de la API, se conectan con el servicio y le envían los mensajes que generan. Existen implementaciones muy complejas, con filtros a través de expresiones regulares, firmas digitales para evitar la manipulación directa de los mensajes, el reenvío de los mismos a otros sevidores de bitácoras, etc.. Syslog al ser parte de POSIX, tiene una API bien definida donde cada mensaje tiene una categoria de severidad y una categoria de tipo de aplicación que la genera. No obstante esto nos puede parecer insuficiente, o queremos formatear nuestros mensajes de bitácora de cierta forma especial, o simple y llanamente no queremos depender de un servicio como syslog. Es cuando recurrimos a las bibliotecas de bitácoras.

La más famosa por innovadora en su época fue la log4j de la fundación Apache. Posteriormente han aparecido clones de la misma biblioteca para diferentes lenguajes y otras muchas implementaciones que atacan el mismo problema desde otros ángulos. Sin embargo, como dijo Brooks hace ya tiempo, no existen las balas de plata que resuelvan todos nuestros problemas de un brochazo. En muchas ocasiones habrá que implementar nuestro subsistema de bitácoras con los requerimientos especiales que tengamos.

Cierro, tal vez prematuramente estas líneas porque me estoy quedando dormido sobre el teclado, con la invitación que profesionalicen sus manejo de bitácoras para su aplicación. Su vida será más sencillas, sus usuarios harán mejores reportes de bugs, su programación será más productiva y su aplicación será más estable al saber exactamente que está pasando dentro de ella.