Dos opciones para Loggear ...

[Jonathan Vila López]

Hola.

Tengo una duda que me surge ahora que estoy definiendo la arquitectura del nuevo proyecto......

Habitualmente usamos Log4j para dejar "rastro" de debug o de informacion necesaria para el debug , y aparte guardamos registro de ciertas operaciones en la base de datos.

Mi idea es usar el sistema de logging para guardar ambos datos......

Opcion A : usar SLF4J y dependiendo del logger usar un appender que me ponga los mensajes en un fichero, o que ademas me envie un mail o que ademas me lo guarde en la base de datos

Opcion B : usar ActiveMQ para que con un sistema de topics yo vaya dejando los mensajes ( y objetos ) en esa cola y dependiendo del filtro con unas rutas de Camel en unos caso coja los debug y los ponga en los ficheros y en otros casos ponga los INFO en otro sitio y en otros casos para Levels personalizados ponga esa informacion que vaya a ser guardada en DB y enviada por mail.

La opcion A parece mas rapida y mas "ligera" o menos compleja , pero en cambio la opcion B me permite mucha mas flexibilidad a la hora de personalizar que hace aquel que lee los mensajes a parte de ademas añadir mas informacion al mensaje que se registra.

Como lo veis ? que opciones os "mola" mas ? y porque ?

[José Guitart]

Hola.
Yo personalmente me quedaría con la a.
Es cierto que no da tanta flexibilidad, pero lo que me estás describiendo no es una función que vaya a cambiar en el tiempo.
La flexibilidad y potencia de la opción b me parece fantástica, pero me da a mi que sería un poco matar moscas a cañonazos, ¿no?

José Guitart

—
Sent from Mailbox

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-ju...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[David Villacampa]

Hola,

La B mola más ;)

Un saludo,

Salutacions / Best regards,

David Villacampa

-------- Missatge original --------
De: José Guitart <jose.g...@gmail.com>
Data: 15/04/2014 18:15 (GMT+01:00)
A: barcel...@googlegroups.com
Assumpte: Re: { Barcelona JUG } Dos opciones para Loggear ...

[Loïc Prieto]

La opción de la cola de mensajes que reparte la carga según el tipo de mensaje es algo que resuena fuertemente en mi alma de programador friki con ganas de probar cosas, pero creo que se puede conseguir exactamente la misma funcionalidad con Log4J, con distintos "plugins" o escritores, o lo que sea que se llame a la clase que puedas escribir para escribir los mensajes donde tu digas que se salga de lo normal. Es decir, el tiempo de desarrollo invertido en establecer esta cola, que además incremente la complejidad del subsistema de loging bastante, tal vez no merezca la pena, cuando se puede resolver de forma más sencilla y directa con un Appender personalizado.
Ahora bien, es cierto que la solución de la cola seguramente escale bastante mejor con muchos nodos y ordenadores/bases de datos dedicados al tema de log y auditoría. De hecho, vería mejor la opción B para un sistema completo de trazado y registro de eventos de la aplicación, que tarde o temprano acaba apareciendo durante el desarrollo.

[Jonathan Vila Lopez]

El tema de usar la opción B es porque en realidad  a los loggers solo les puedes pasar texto y un level por lo que la personalización tampoco puede ser mucha.
Además lo que no me gusta es que la configuración de los appender se hace en  el mismo proyecto y al final tendría tantos appenders cómo proyectos (bundles).
La otra opción permite aislar el tratamiento de los logs de los proyectos aunque añade complejidad. Mi propuesta es porque no tan sólo voy a Loggear mensajes de texto,  sino mas cosas...

Me gustan vuestras propuestas.

[José Guitart]

Pero los logs son sólo logs o va a haber un tratamiento posterior de los datos?

—
Sent from Mailbox

[Jonathan Vila Lopez]

Es que quiero aprovechar el sistema de log para guardar info de debug, errores, tracking, etc
Pero además dependiendo del tipo de log luego se enviará por mail o se guardará en base de datos, etc.  Pero no solo un mensaje sino una info que puede ser compleja.

[David Villacampa]

No hay problema en tener muchos appenders

Salutacions / Best regards,

David Villacampa

-------- Missatge original --------

De: Jonathan Vila Lopez <jonath...@gmail.com>
Data: 15/04/2014 19:37 (GMT+01:00)
A: "barcelona-jug@googlegroups com" <barcel...@googlegroups.com>

[Loïc Prieto]

En una empresa en la que estuve, tenían montado un sistema de logueo de eventos y todo tipo de información arbitraria unificado para todas sus aplicaciones, de tal forma que estaba separado físicamente y podía escalar de forma independiente, con n nodos y n bases de datos en sharding (usaban Oracle, pero este tipo de datos los veo más en un Big Data por su volumen potencial y las capacidades de agregación posteriores). Para lo que quieres, y si lo ves a lo grande, creo que estaría bastante guay la propuesta de la cola que haces. Escribes los eventos en un topic y que se transformen/procesen por los canales que sean, y lleguen al final a este sistema independiente que permita monitorizar y analizar después, en plan BI...pero en técnico. Veo este sistema perfecto para análisis de consumo, y apoyo a la toma de decisiones estratégicas, no sólo para logueo de errores de la aplicación.

Me gusta mucho el sistema, si consigo estar más de un año en esta empresa, igual propongo algo similar!

[Nacho Cougil Jares]

Muy buenas.

Sin lugar a dudas la flexibilidad que te da la opción B no la puedes tener con la A, a no ser que todos los proyectos se configuren, adapten, etc bajo el mismo prisma (cosa bastante complicada si al final cada equipo de desarrollo gestiona su propio log para guardar lo que le parezca, etc). Por este motivo y también en base a la necesidad de poder clasificar, gestionar, etc todos los logs en base a los criterios que necesites. Es más, la opción B te puede permitir diseñar un componente que simplemente se encargue de loggear, pero su configuración sea común a todos los proyectos x entorno cosa que desde log4j es siempre complicado de mantener (mis rutas están aquí o allí, mis appenders son asá, mi rolling no es el mismo, etc)

Vamos, que aunque + complicada yo me quedaría con la B ;-)

Saludets,

El miércoles, 16 de abril de 2014 09:46:33 UTC+2, Loïc Prieto escribió:

En una empresa en la que estuve, tenían montado un sistema de logueo de eventos y todo tipo de información arbitraria unificado para todas sus aplicaciones, de tal forma que estaba separado físicamente y podía escalar de forma independiente, con n nodos y n bases de datos en sharding (usaban Oracle, pero este tipo de datos los veo más en un Big Data por su volumen potencial y las capacidades de agregación posteriores). Para lo que quieres, y si lo ves a lo grande, creo que estaría bastante guay la propuesta de la cola que haces. Escribes los eventos en un topic y que se transformen/procesen por los canales que sean, y lleguen al final a este sistema independiente que permita monitorizar y analizar después, en plan BI...pero en técnico. Veo este sistema perfecto para análisis de consumo, y apoyo a la toma de decisiones estratégicas, no sólo para logueo de errores de la aplicación.

Me gusta mucho el sistema, si consigo estar más de un año en esta empresa, igual propongo algo similar!

El 16 de abril de 2014, 8:59, David Villacampa <dvill...@alyda.net> escribió:

No hay problema en tener muchos appenders

Salutacions / Best regards,

David Villacampa

-------- Missatge original --------

De: Jonathan Vila Lopez <jonath...@gmail.com>
Data: 15/04/2014 19:37 (GMT+01:00)

A: "barcelona-jug@googlegroups com" <barcelona-jug@googlegroups.com>

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-jug+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-jug+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-jug+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-jug+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-jug+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito al grupo "Barcelona JUG" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-jug+unsubscribe@googlegroups.com.

[Toni Tassani]

Jonathan,

Yo primero de todo aclararía de qué se necesita hacer log, quien lo va a usar, y para qué.

Una vez aclarado eso (incluido el tiempo de retención de los logs) valoraría si es necesario guardarlo en base de datos o no (porque es un dolor de cabeza).

Hay cosas que es necesario registrar por cuestiones de seguirdad, cosas que hay que registrar para tener trazabilidad de incidencias, y otras cosas que es necesario registrar por la propia necesidad funcional de la aplicación.

Log4j, SLF4J y familia, van muy bien para logging para programadores y para gente de operación. Checks del estado de la aplicación o de trazabilidad, pero no van nada bien para logging de aplicación, y pueden suponer un severo cuello de botella cuando registran en base de datos. En el caso de trabajar con Base de Datos, las colas pueden ayudarte a mitigar el cuello de botella.

Mi preferencia sería:

a) Para logging de programador y operaciones (p.ej. en tratamiento de excepciones, estilo fichero no existe y demás). Es sencillo. No complica la arquitectura. Es conocido por cualquier desarrollador.

b) Para logging a nivel de aplicación (p.ej. usuario de categoría C ha hecho descarga de todos estos datos que son confidenciales). Puede ser arbitrariamente complejo, si responde a unas necesidades de negocio claras.

El logging que nadie lee y nadie usa, no sirve para nada.

Saludos

Toni

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a barcelona-ju...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Toni Tassani
Blog http://alapamui.blogspot.com/

Twitter @atassani

[Alex Soto]

Para guardar logs en entornos persistentes, monitorizables y rápidos recomiendo logstash. Logstash está basado en elasticsearch lo que lo hace una herramienta muy pontente para hacer búsquedas, agrupaciones, indexaciones y  monitorización.

El dimarts 15 d’abril de 2014 17:29:43 UTC+2, Jonathan Vila López va escriure: