SFL4J y JCL. Estandares de logging

Desde que comenzamos con el desarrollo de aplicaciones siempre hemos tenido la premisa de evitar las sentencias System.out para depurar nuestro código. Es una buena práctica insertar en el código de nuestras aplicaciones las sentencias apropiadas de log para depurar correctamente los fallos que se puedan producir. En determinadas ocasiones lo ideal será tener un sistema de log que persista los mensajes de logs de nuestras aplicaciones en una base de datos y se comunique con nuestras aplicaciones mediante colas JMS, pero esto es algo más complejo que trataremos en una futura ocasión.

Todos o casi todos los que  hemos desarrollado aplicaciones Java hemos utilizado JCL (Java Commons Logging), una capa de abstracción que permite conectar varias implementaciones como log4j o commons loggings. La implementación de log4j se ha convertido en un estandar de facto para realizar el log de nuestras aplicaciones. 


JCL permite cambiar la API que vamos a utilizar de forma dinámica en tiempo de ejecución. Esto puede provocar algún que otro problema con los classloaders. Además de este hay otros problemas que seguro que habréis sufrido en vuestros desarrollos como la necesidad de algún appender determinado que no teníamos (alguna vez he tenido que implementar algún appender que rotase por día y por tamaño...)

El sucesor natural de JCL es SLF4J. Al igual que el primero, es una capa de abstracción que permite que utilicemos varias implementaciones (logback, log4j) pero a diferencia de JCL la implementación queda ligada cuando desplegamos nuestra aplicación mediante un JAR puente.

Las mejoras principales al utilizar SLF4J son las siguientes:

• Se acaban los problemas con los classloaders, al ligarse la API de implementación estáticamente y no dinámicamente como en JCL.

• Trazas con parámetros más sencillas.

• Independencia, puesto que puedes añadir múltiples vinculaciones añadiendo un nuevo JAR. 

Hoy leo en JavaHispano una noticia sobre logback 1.0, el sucesor de log4j. En el artículo nos muestra un link con las razones de migrar a logback 1.0.  Logback es una implementación de SLF4J creada por el mismo autor que log4j Ceki Gülcü. A continuación os enumero una lista de buenas razones para pasarse a logback:

• Cambios en caliente desde JMX. Con la clase JMXConfigurator podemos recargar la configuración de logback desde un fichero por defecto, desde un fichero existente o una URL. Podremos modificar la lista de nuestros loggers y sus niveles de log.

• Uso de variables en las rutas de ficheros. Ya no tendremos que indicar rutas absolutas para nuestros file appenders.

• Filtros. Los filtros no parecen en principio algo fundamental, pero en grandes aplicaciones desplegadas en un entorno de producción nos pueden servir de mucho. Imaginemos que tenemos un terminal bancario en producción y que ocasionalmente ocurre un error. Normalmente el nivel de log en este entorno es de INFO o WARN así que detectar los errores es más complicado. Imaginemos que este error no se puede reproducir en el entorno de validación debido a las diferencias existentes entre ambos entornos. Con log4j, para detectar este problema, debemos bajar el nivel de log a DEBUG e intentar analizar los logs para comprobar que sucede, con el correspondiente impacto en el rendimiento de la aplicación. Sin embargo, con  logback podemos crear un filtro para que acepte los logs de DEBUG de un usuario determinado (el encargado de detectar el problema) y siga escribiendo sólo los logs de WARNING o INFO para el resto de usuarios de producción. 

• RollingFileAppender ha sido mejorado. Muchas veces sólo queríamos mantener los logs de nuestra aplicación durante un año. Ahora configurando nuestro RollingFileAppender con un RollingPolicy podemos indicar mediante la propiedad maxHistory el número de días o meses que queremos mantener nuestros ficheros logs. También nos permite comprimir los ficheros de logs asincronamente para que no afecte al rendimiento con grandes volumenes de datos.

• Layout mejorados. Permiten limitar el tamaño de la pila de excepciones en los logs. 

• Lilith es una aplicación GUI para visualizar los logs de logback tipo Apache Chainsaw. Está preparado para manejar grandes volumenes de datos. También hay un plugin de Eclipse que te permite hacerlo.

• El rendimiento es mucho mayor, basándose en log4j, el código ha sido reescrito para en algunos casos ser 10 veces más rápido. 

• Batería de pruebas más robusta que en log4j.

• Posibilidad de configurar logback en XML y también con Groovy.

• Documentación muy extensa.

• Una de las características nuevas de logback que más me ha gustado y que más he sufrido con log4j es la escritura segura de varios appenders en el mismo fichero. Mediante la propiedad prudent varias instancias de FileAppender corriendo en varias JVMs (por ejemplo en un entorno de cluster) realizaran una escritura segura del mismo fichero de log. La clase FileAppender y todas sus subclases (RollingFileAppender) se pueden recuperar de errores I/O y pueden seguir funcionando sin reiniciar la aplicación.

• En los ficheros de configuración podemos emplear condiciones (if-then-else) para realizar pequeños cambios de configuración de logs entre los diferentes entornos que tengamos (desarrollo, test , producción) sin tener que duplicar ficheros. 

• Las trazas de las excepciones en los ficheros de logs contienen información de los paquetes de las clases. Esto en ocasiones nos puede resultar muy útil porque además de saber qué clases provocan el error, también nos informa de la versión a la qué pertenecen.

Por todas estas razones, creo que deberíamos migrar nuestras aplicaciones a logback. En definitiva, es una versión mejorada de nuestro querido log4j. Podemos utilizar el SFL4JMigrator, herramienta que nos ayuda a migrar nuestras aplicaciones en pocos minutos. Podéis leer un artículo de mi amigo y compañero de batallas el señor Fuente para profundizar más sobre este tema.

Referencias: logback |  balteus