DMReMon Monitor de Recursos Multiplataforma con entorno de desarrollo

Tecnologías utilizadas

• Herramientas de logging

  • Introducción

    Las herramientas de logging permiten a los programas (y a los programadores) volcar información de lo que sucede en la ejecución de los mismos, normalmente en archivos de texto. Debido a la complejidad de los programas actuales, los logs son muy importantes para saber lo que está ocurriendo en la ejecución de un programa. Mediante los logs es posible detectar fallos que hayan ocurrido en un programa después de que éstos se hayan producido y de esta manera poder evitar consecuencias peores.

    Una de las mayores ventajas de cualquier API de logging sobre la tradicional impresión de información en pantalla o en un fichero (el clásico printf de C o el System.out.println de Java) es que permite habilitar y deshabilitar ciertos logs mientras otros no sufren ninguna alteración. No es raro que en cualquier programa se nos "cuele" alguna impresión de alguna línea que indique en qué punto del programa se está ejecutando. Gracias a las herramientas de logging este problema puede ser controlado fácilmente.

  • Log4J

    Log4J [14] (pronunciado como "Log for Java") es un producto Open Source desarrollado por el grupo Apache que permite a los desarrolladores controlar la salida de sus mensajes y hacia donde son direccionados con gran granularidad. Esta herramienta es completamente configurable en tiempo de ejecución utilizando archivos externos de configuración. Aunque Log4J inicialmente fue desarrollado para Java, debido a su gran popularidad ha sido implementado en otros muchos lenguajes como: C, C++, C#, Python, Ruby, Eiffel, PHP, etc.

    Log4J tiene por defecto 5 niveles de prioridad para los mensajes de logs:

    • DEBUG: Se utiliza para escribir mensajes de depuración. Este log no debe estar activado cuando la aplicación se encuentre en producción.
    • INFO: Se utiliza para mensajes similares al modo "verbose" en otras aplicaciones.
    • WARN: Se utiliza para mensajes de alerta sobre eventos de los que se desea tener constancia, pero que no afectan al correcto funcionamiento del programa.
    • ERROR: Se utiliza en mensajes de error de la aplicación que se desean guardar. Estos eventos afectan al programa pero lo dejan seguir funcionando, como por ejemplo que algún parámetro de configuración no es correcto y se carga el parámetro por defecto.
    • FATAL: Se utiliza para mensajes críticos del sistema. Generalmente, después de guardar el mensaje el programa se aborta.

    Adicionalmente a estos niveles de log, existen dos niveles extras que sólo se utilizan a nivel de configuración:

    • ALL: Este es el nivel más bajo posible. Habilita todos los logs.
    • OFF: Este es el nivel más alto posible. Deshabilita todos los logs.

    Además de las posibilidad de elegir prioridad para los mensajes de logs, Log4J permite que los mensajes de logs se impriman en múltiples destinos. En Log4J un destino de salida se denomina Appender. Las distintas posibilidades que ofrece son:

    • ConsoleAppender: Vuelca el log en la consola.
    • FileAppender: Redirecciona los mensajes de logs a un archivo.
    • RollingFileAppender: Redirecciona los mensajes de logs hacia un archivo, con la posibilidad de definir políticas de rotación para que el archivo no crezca indefinidamente.
    • DailyRollingFileAppender: Redirecciona los mensajes de logs a un archivo, con la posibilidad de definir políticas de rotación basadas en la fecha.
    • SocketAppender: Redirecciona los mensajes de logs hacia un servidor remoto de log. En este caso, el mensaje de log se almacenará en el servidor remoto sin sufrir alteraciones en los datos, exactamente como si se hubiera guardado en local.
    • SMTPAppender: Envía un correo electrónico con los mensajes de logs. Típicamente se utiliza para los mensajes ERROR y FATAL.
    • JDBCAppender: Redirecciona los mensajes de log hacia una base de datos.
    • SyslogAppender: Redirecciona los mensajes de logs hacia el demonio syslog (sólo para el sistema operativo Linux).
    • NTEventLogAppender: Redirecciona los mensajes de logs hacia los logs del sistema de NT (sólo para Windows).
    • JMSAppender: Serializa los eventos y los transmite como un mensaje JMS tipo ObjectMessage.

    Log4J también permite definir el formato de los mensajes de logs. Estos formatos se definen mediente layouts. Los tipos de layouts son:

    • SimpleLayout: Especifica el formato de salida mediante la prioridad del mensaje, seguido por "-" y el mensajes de log.
    • PatternLayout: Especifica el formato de salida de los mensajes de logs de acuerdo a unos patrones de conversión similares a los utilizados en la función printf del lenguaje C.
    • HTMLLayout: Especifica que la salida de los eventos será en una tabla HTML.
    • XMLLayout: Especifica que la salida será a un archivo XML que cumple con el DTD log4j.dtd.

    Finalmente, en lo que se refiere a rendimiento, el objetivo principal de Log4J es la velocidad aún por encima de la flexibilidad. Uno de los argumentos utilizados en contra de realizar logging es el coste computacional. Esto no debería ser un problema para las aplicaciones "normales" (si lo podría ser para aplicaciones en tiempo real). Para ver que el rendimiento no se ve "seriamente" afectado, se deben tener en cuenta los siguientes puntos (los tiempos son tomados con un Pentium II de 233 MHz):

    • Rendimiento del sistema cuando el logging está desactivado: Cuando el log se encuentra desactivado, el coste de la llamada al log está en torno a los 5-50 nanosegundos.
    • Rendimiento cuando se tiene que decidir si el nivel de log se encuentra activado o no: El rendimiento apenas se ve afectando pues el tiempo que se tarda en comprobar si un nivel está activado es 3 veces menor que comprobar si el log está desactivado completamente..
    • Formateo de los mensajes: Este es el coste de formatear la salida y enviarlo al destino adecuado. El coste de enviar un log es alrededor de 100 a 300 microsegundos.

    Por tanto, viendo las distintas posibilidades que ofrecen estas herramientas, las ventajas que aportan y el rendimiento que ofrecen, parece claro que es recomendable utilizar herramientas de logging en las aplicaciones, a excepción de los sistemas de tiempo real.