java - name - logback spring boot

Mejores prácticas para usar marcadores en SLF4J/Logback

Question

Estamos utilizando la combinación de SLF4J + Logback en nuestro proyecto desde hace un tiempo y estamos muy contentos con ella, pero nuestra estrategia de registro es bastante simple, usando loggers basados ​​en clases simples 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 se usaría ^[1] Marcadores para el registro. Me parecen una buena característica para agregar contexto semántico al registro: por ejemplo, mientras una clase puede manejar múltiples preocupaciones, se pueden usar marcadores específicos de tarea / preocupación para discriminar 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 que lo que realmente persigo no es tanto por qué usar marcadores, sino la parte cómo , ¿hay algunas buenas prácticas para nombrar marcadores (por ejemplo, usar texto sin formato con espacios o guiones / guiones bajos / signos de estilo de palabras clave delimitados por puntuación? ), debería haber algún tipo de grupo de "nombres estándar", nombrando cosas basadas en las funciones de negocios. Las preguntas que probablemente pueda resolver por mi cuenta, pero si quiero utilizar estas funciones sistemáticamente y presentarlas a un equipo de desarrolladores, tiene sentido tener algunas pautas formalizables en torno a ...

^[1] - Al preguntar cómo usar los marcadores, realmente no estoy preguntando cómo usar la API (en realidad es bastante sencillo). Me refiero más bien al nivel más general de cómo se configuraría el inicio de sesión utilizando marcadores consistentemente.

Answer 1

Al igual que una adición, si está utilizando logstash y tiene habilitado el registro json, existe otro uso potencial de Marker: para registrar variables que se asocien con un mensaje de registro específico. Esto es más consistente 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

Answer 2

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 del marcador.

1. Disparando : Algún appender podría ser instruido para realizar una acción en presencia de un marcador determinado. Por ejemplo, SMTPAppender se puede configurar para enviar un correo electrónico siempre que un evento de registro esté marcado con el marcador NOTIFY_ADMIN independientemente del nivel de registro. Consulte la activación basada en marcador en la documentación de inicio de sesión. También puede combinar niveles de registro y marcadores para desencadenar.

2. Filtrado : podría, por ejemplo, colorear / marcar todos los registros relacionados con la persistencia (en varios y varios archivos de clase) con el color "DB". A continuación, puede filtrar para "DB": deshabilitar el registro a excepción de 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).

Answer 3

Primero, MDC.

MDC es realmente útil en un entorno donde tienes una "entidad" que está asociada con algún comportamiento. Un ejemplo típico: el usuario interactúa con una aplicación web. Entonces, digamos que tiene muchos usuarios jugando con su aplicación web. Al usar MDC, puede rastrearlos fácilmente sin demasiada molestia. 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á usando MDC en dos lugares: para nombre de usuario y para ID de sesión. De esta manera, puede grep fácilmente la sesión de un usuario para ver todo lo que han estado haciendo.

En segundo lugar, marcadores.

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

O bien, cuando un usuario abandona su servicio, por lo general 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 dejan de fumar.

Regla de oro:

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

Answer 4

Primero, como dijo @darioo:

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

Entonces, tu afirmación de que quieres usar MDC para esto. Los marcadores son para resaltar eventos "especiales", filtrando, si se quiere, en lugar de "cortar". Por ejemplo, puede dividir según un usuario en particular, pero filtrar según excepciones inesperadas. En este caso, crearía una dimensión de usuario MDC y un marcador de excepción inesperada .

Pero aparentemente esto no aborda la pregunta que tenías en mente. Usted "se refiere más bien al nivel más general de cómo se configuraría el inicio de sesión utilizando marcadores de forma consistente". Así que vamos a abordar 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 produzca la prueba / producción. Cada dimensión tiene una dimensión MDC. Cada caso tiene un marcador. Es tan simple como eso.

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

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 para que no sea probable que entre en conflicto con adiciones posteriores. Los guiones y los guiones bajos son excesivamente quisquillosos y alarmantes además del punto, 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, esto molesta, según se informa, a algunos desarrolladores debido a la incomodidad de alcanzar las claves requeridas.

En lo que respecta a la decisión sobre una política, esto solo significa definir en qué casos se debe emplear una dimensión determinada de Marcador o MDC . Mantenga esta estrecha (centralizada, deliberada), pero permita la retroalimentación 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. Imagina algunos escenarios de pesadilla. Luego imagine cómo le gustaría poder analizar los registros en ese escenario. Probablemente no quiera tener que escribir un script complicado para tratar de rastrear qué mensaje pertenece a qué contexto, y qué estado es cuál en ese momento, ¿no? Codifique la información necesaria como dimensiones y marcadores, y ahórrese algunas molestias si algo sale mal.