Mostrando las entradas con la etiqueta logging. Mostrar todas las entradas
Mostrando las entradas con la etiqueta logging. Mostrar todas las entradas

martes, julio 21, 2009

Plugin pattern

Como inicio de una seria de articulos sobre patrones empiezo con uno muy relacionado con mi ultimo post,

Patron Plugin.

“Links classes during configuration rather than compilation.” (Fowler, POEAA, p.4990)[1]

El patrón Plugin permite agregar funcionalidad a nuestro sistema en forma dinámica utilizando configuración, por lo general se usan en frameworks que permitan agregar nuevas formas de implementar funcionalidades ya existente, por ejemplo el log4net [2] permite agregar nuevas implementaciones para los adaptadores a los repositorio donde registrar los mensajes de Log (IAdapter) o formato de los mensajes (IFormater).
Otro sistema que usaba el patrón plugin fue el EDRA de P&P, este framework implementaba el patrón Pipes & filters [3] en donde se podían agregar handlers que ejecuten determinada funcionalidad antes de ejecutar una acción personalizada, después o en ambos casos, ejemplo de un handler de “antes” sería un handler de autenticación, de “después” un handler de validación del formato de respuesta y para ambos casos un handlers que agregue información adicional al mensaje de entrada y al de salida a la acción, por ejemplo para medir tiempo transcurrido entre le ejecución de la llamada a la acción y la recepción del mensaje de respuesta.

Otro ejemplo de implementación del patrón plugin es cuando se usa en la implementación del patrón Chain and Responsability [4], básicamente en este patrón participan un conjunto de objetos de comandos y una serie de objetos de procesamiento, mediante configuración se pueden agregar en forma dinámica nuevos objetos de comandos.
Para implementar este patrón el sistema a extender debe disponer de un mecanismo de configuración donde se puedan agregar los nuevos componentes que implementan interfases definidas para determinadas funcionalidades del sistema.
Siguiendo con el ejemplo de log4net el archivo de configuración de la figura se indica el mecanismo que utiliza este Framework para aplicar el patrón plugin.

En este ejemplo se tienen 3 appenders, uno que envía los registro de Log a la consola, el segundo a un archivo que puede llegar a un máximo de 100kb (y luego se genera otro) y un aprender personalizado que envía los logs a otro repositorio no contemplado en la configuración estándar de log4Net (por ej MSMQ o WCF).



Mas info

[1] Pattern to Enterprise Applications Architecture - Pluging Pattern ,http://martinfowler.com/eaaCatalog/plugin.html

[2] Log4Net Framework , http://logging.apache.org/log4net/index.html

[3] Enterprise Integration Patterns – Pipes & Filters , http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html

[4] Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)

lunes, julio 13, 2009

Logging and trace.

En este post subo información sobre unos de los servicios cross más importantes a considerar en el diseño de un arquitectura empresaria, que es logging y trace de los eventos y errores que surgan en la aplicación. Se analizan las carácteristicas más importantes, los anti patrones, las buenas prácticas y los patrones de diseño aplicados. Al final se indican algunos frameworks de logging para diferentes plataformas y lenguajes de programación.


Objetivo:
Registrar eventos de relevancia para utilizarlos en procesos de auditoria o troubleshuting post mortem.
Es una herramienta muy útil en ambientes productivos donde es imposible depurar con herramientas de desarrollo.
Los eventos pueden ser información de depuración o errores ocurridos en la aplicación.

Características deseables de un sistema de logging:
Configuración de niveles de log

Formateo de eventos
Agregado de información adicional en publicación de eventos
Logging asincrónico
Logging confiable
Logging centralizado
Configuración jerárquica y dinámica
Publicación a múltiples destinos
Aplicación para visualizar y analizar los eventos.


Anti patrones:


Todo en un mismo mensaje: Todo junto en un mismo archivo es muy dificil de analizar.

Registro de datos incompletos:Registrar lo que sirva para, ni más ni menos.

Log sin formato o formato no consistente: Si el log no está estructurado, su analisis se hace muy dificil.

Entradas multi línea: Complica el procesamiento de log para pasarlo a una DB o aplicación que muestre la información en forma amigable.


Registrar mensajes relacionados a un mismo contexto en varias líneas: Muy dificil de analizar lo que pasó en un determinado contextode ejecución.


Buenas prácticas:


Registrar los logs en repositorio con formato, esto facilita en análisis de los logs registrados.

Separar los mensajes en diferentes destinos dependientes de la audiencia que los usa, por un log de auditoria puede tener muchas más información de la necesario para resolver un problema que ocurrió en la aplicación.

Registrar las acciones antes de que ocurran



Evitar que los archivos de logs sean muy grandes, se recomienda archivarlos y crear uno nuevo.

Registrar los eventos en una sola línea, es más fácil de analizar y filtrar. Si la información tiene formato complejo se recomienda usar xml.

Usar formato consistente en un mismo archivo.


Patrones utilizados


Estrategia:

Se puede usar para seleccionar la forma en que el sistema de log registra los eventos y errores.




Pipes and filters:

Se usa para tener un mecanismo extensible y de bajo acoplamiento para agregar información contextual y codificación a los mensajes antes de enviarlo al repositorio de logging.




Consideraciones de implementación:


Por lo general son frameworks muy flexibles, que soporta multiples fuentes y destinos, por lo tanto para implementarlo adecuadamente se requiere un buen análisis de que funcionalidades usar y cual es su mejor forma de implementar.

Otros frameworks de logging e instrumentación.

Java:
log4J
y de este log4Net, log4PHP, log4JavaScript, log4C, log4VB, log4SQL, log4PLSQL etc

AJAX:
log4javascript
, JSLog, Lumberjack, log4Js, jsTracer

Unix like: syslogd (nativo).

Bibliografía


Carácteristicas
http://gojko.net/2006/12/09/logging-anti-patterns/

Frameworks
Pattern & Practices Logging Application Block
Apache Log4Net

Patrones
http://www.dofactory.com/Patterns/PatternStrategy.aspx
http://msdn.microsoft.com/en-us/library/ms978599.aspx