Mejores prácticas para usar marcadores en SLF4J / Logback

Estamos utilizando la combinación SLF4J + Logback en nuestro proyecto desde hace un tiempo y estamos muy contentos con él, pero nuestra estrategia de registro es bastante simple, utilizando registradores directos basados ​​en clases y sin elementos sofisticados como MDC o Markers.

Lo que quiero saber es si alguien en la comunidad realmente usa estas características y cómo se usan para mejorar el registro / filtrado.

Estoy especialmente interesado en dónde, por qué y cómo usaría ^[1] Marcadores para iniciar sesión. Me parecen una característica bastante clara para agregar contexto semántico al registro; por ejemplo, si bien una clase puede manejar múltiples preocupaciones, uno puede usar marcadores específicos de tareas / preocupaciones para discriminar las declaraciones de registro.

Cuáles pueden ser las mejores prácticas, convenciones o estrategias para crear y usar marcadores en el registro.

Actualización: supongo, lo que realmente busco no es tanto por qué usar marcadores, sino más bien la parte del cómo : ¿hay algunas buenas prácticas para nombrar marcadores (por ejemplo, usar texto sin formato con espacios o guiones / guiones bajos / signos de puntuación delimitados por nombres de estilo de palabra clave ), debería haber algún tipo de grupo de "nombres estándar", nombrando cosas basadas en las funciones comerciales. Probablemente pueda resolver las preguntas por mí mismo, pero si quiero usar estas características sistemáticamente y presentarlas a un equipo de desarrolladores, tiene sentido tener un conjunto formal de pautas en torno a ...

^[1] - Al preguntar cómo usar marcadores, en realidad no estoy preguntando cómo usar API (es realmente bastante sencillo), sino que me refiero al nivel más general de cómo se configuraría el inicio de sesión utilizando marcadores de manera consistente

Primero, como dijo @darioo:

• MDC se usa para asociar múltiples eventos con pocas "entidades"
• [Marcadores] se utilizan para eventos "especiales" que desea filtrar de los habituales

Entonces su afirmación de que desea utilizar MDC para esto. Los marcadores son para resaltar eventos "especiales" - filtrado, si lo desea - en lugar de "segmentar". Por ejemplo, puede dividir en función de un usuario en particular, pero filtrar en función de cualquier excepción inesperada. En este caso, crearía una dimensión MDC de usuario y un marcador de excepción inesperada .

Pero esto aparentemente no responde a la pregunta que tenía en mente. Se está "refiriendo más bien al nivel más general de cómo se configuraría el inicio de sesión utilizando marcadores de manera consistente". Entonces abordemos eso:

MDC es para cortar y cortar en cubitos , y los marcadores son para filtrar . Estas actividades se llevan a cabo durante las pruebas y en la producción . Como tal, debe decidir qué dimensiones espera que sean útiles para dividir los datos de registro y en qué casos podría ser útil filtrarlos cuando se realiza la prueba / producción. Cada dimensión obtiene una dimensión MDC. Cada caso recibe un marcador. Es tan simple como eso.

Los desarrolladores no necesitan tomar ninguna decisión aquí. Una sola persona o equipo debe decidir, en el momento del diseño , qué tipo de corte, corte en cubitos y filtrado debe ser compatible. Esto debe informarse imaginando qué tipo de tareas de análisis uno espera que se les pida que realicen.

Esta misma persona o equipo debe decidir sobre la convención de nomenclatura. Es completamente arbitrario . Elija algo que sea estéticamente agradable, autodescriptivo (lo más importante) y lo suficientemente específico como para que sea poco probable que entre en conflicto con adiciones posteriores. Guiones vs. bajos son extremadamente puntiagudos y alarmantemente irrelevantes, pero tenga en cuenta que puede ser menos confuso para los empleados de ESL leer guiones bajos (al menos en comparación con CamelCase); Al mismo tiempo, según los informes, esto molesta a algunos desarrolladores debido a la incomodidad de alcanzar las claves necesarias.

En cuanto a decidir sobre una política, esto solo significa definir en qué casos debe emplearse un determinado marcador o dimensión MDC . Mantenga esto estricto (centralizado, deliberado), pero permita comentarios de los desarrolladores si sienten que el conjunto de dimensiones y marcadores son insuficientes para la tarea en cuestión. Revise / agregue dimensiones y / o atributos según corresponda.

Comprenda que esta política será casi necesariamente específica del proyecto . No todos los proyectos necesitan el mismo tipo de análisis de registro. Imagine algunos escenarios de pesadilla. Luego imagine cómo le gustaría poder analizar los registros en ese escenario. Probablemente no desee tener que escribir un guión complicado para tratar de rastrear qué mensaje pertenece a qué contexto y qué estado es en qué momento, ¿verdad? Codifique cualquier información que sea necesaria como dimensiones y marcadores, y ahórrese parte de la molestia si algo sale mal.

Primero, MDC.

MDC es realmente útil en un entorno donde tiene una "entidad" que está asociada con algún comportamiento. Un ejemplo típico: usuario que interactúa con una aplicación web. Entonces, supongamos que tiene muchos usuarios jugando con su aplicación web. Con MDC, puede rastrearlos fácilmente sin demasiados problemas. Ejemplo simplificado:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Aquí, está utilizando MDC en dos lugares: para nombre de usuario y para ID de sesión. De esta manera, puede seleccionar fácilmente la sesión de un usuario para ver todo lo que ha estado haciendo.

En segundo lugar, los marcadores.

Los marcadores generalmente se usan para circunstancias "especiales", como el envío de un correo electrónico a un administrador por algunos errores críticos graves. No todos los errores siempre caen en la misma categoría; algunos tienen que ser tratados de manera apropiada.

O, cuando un usuario abandona su servicio, generalmente va a un registro INFO, pero también puede usar un marcador para tales casos, si desea que eventos como este vayan en un archivo de registro separado, para que pueda monitorearlo más fácilmente para la recopilación estadística de usuarios que abandonan.

Regla de oro:

• MDC se usa para asociar múltiples eventos con pocas "entidades"
• los marcadores se utilizan para eventos "especiales" que desea filtrar de los habituales

Los marcadores se pueden usar para colorear o marcar una sola declaración de registro. Lo que hagas con estos colores, es decir, marcadores, depende totalmente de ti. Sin embargo, dos patrones parecen ser comunes (el primero más común que el segundo) para el uso de marcadores.

1. Disparo : se puede indicar a algunos usuarios que realicen una acción en presencia de un determinado marcador. Por ejemplo, SMTPAppenderse puede configurar para enviar un correo electrónico cada vez que se marca un evento de registro con el NOTIFY_ADMINmarcador, independientemente del nivel de registro. Consulte la activación basada en marcadores en la documentación de inicio de sesión. También puede combinar niveles de registro y marcadores para la activación.

2. Filtrado : podría, por ejemplo, colorear / marcar todos sus registros relacionados con la persistencia (en varios y varios archivos de clase) con el color "DB". Luego puede filtrar por "DB": deshabilite el registro, excepto las declaraciones de registro marcadas con DB. Consulte el capítulo sobre filtros en la documentación de inicio de sesión para obtener más información (busque MarkerFilter).

Al igual que un apéndice, si está utilizando logstash y tiene habilitado el registro json, existe otro uso potencial de Marker: para registrar variables para asociarlas con un mensaje de registro específico. Esto es más coherente y más fácil de analizar que incluirlo en el cuerpo del mensaje. Muy útil, si se adapta a su caso de uso.

Ver detalles aquí:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event