logging - name - Niveles de registro-Logback-regla de oro para asignar niveles de registro

logback spring boot (5)

Estoy usando logback en mi proyecto actual.

Ofrece seis niveles de registro: TRACE DEBUG INFO WARN ERROR OFF

Estoy buscando una regla de oro para determinar el nivel de registro para actividades comunes. Por ejemplo, si un hilo está bloqueado, el mensaje de registro debe establecerse en el nivel de depuración o en el nivel de información. O si se está utilizando un socket, si su identificación específica se registra en el nivel de depuración o el nivel de seguimiento.

Apreciaré las respuestas con más ejemplos para cada nivel de registro.

Esto también puede ayudar tangencialmente, para comprender si una solicitud de registro (desde el código) a un cierto nivel resultará en que realmente se registre dado el nivel de registro efectivo con el que se configura una implementación. Decida con qué respuestas desea configurar el nivel efectivo con el que desea configurar su implementación aquí, y luego consulte esto para ver si realmente se registrará una solicitud de registro particular de su código y luego ...

Para ejemplos :

"¿Una línea de código de registro que se registra en WARN realmente se registrará en mi implementación configurada con ERROR?" La mesa dice, NO.
"¿Una línea de código de registro que se registra en WARN realmente se registrará en mi implementación configurada con DEBUG?" La tabla dice, sí.

de la documentación de logback :

De una manera más gráfica, aquí es cómo funciona la regla de selección. En la siguiente tabla, el encabezado vertical muestra el nivel de la solicitud de registro, designado por p, mientras que el encabezado horizontal muestra el nivel efectivo del registrador, designado por q. La intersección de las filas (solicitud de nivel) y las columnas (nivel efectivo) es el booleano que resulta de la regla de selección básica.

Por lo tanto, una línea de código que solicita el registro solo se registrará realmente si el nivel de registro efectivo de su implementación es menor o igual al nivel de gravedad solicitado de esa línea de código.

Mi enfoque, creo que proviene más de un desarrollo que de un punto de vista de operaciones, es:

Error significa que la ejecución de alguna tarea no se pudo completar; no se pudo enviar un correo electrónico, no se pudo representar una página, algunos datos no se pudieron almacenar en una base de datos, algo así. Algo definitivamente ha salido mal.
Advertencia significa que algo inesperado sucedió, pero que la ejecución puede continuar, quizás en un modo degradado; faltaba un archivo de configuración, pero se utilizaron los valores predeterminados, el precio se calculó como negativo, por lo que se fijó en cero, etc. Algo no está bien, pero aún no ha salido correctamente. Las advertencias son a menudo una señal de que habrá un error muy pronto.
Info significa que algo normal pero significativo sucedió; el sistema se inició, el sistema se detuvo, se ejecutó el trabajo diario de actualización del inventario, etc. No debería haber un torrente continuo de estos, de lo contrario, hay demasiado para leer.
Depurar significa que algo normal e insignificante sucedió; un nuevo usuario llegó al sitio, se procesó una página, se tomó un pedido y se actualizó un precio. Esto es lo que se excluye de la información porque sería demasiado.
Trace es algo que nunca he usado realmente.

No es diferente para otras respuestas, mi marco tiene casi los mismos niveles:

Error: errores lógicos críticos en la aplicación, como un tiempo de espera de conexión de base de datos. Cosas que requieren una corrección de errores en un futuro cercano
Advertir: problemas no importantes, pero cosas por las que hay que prestar atención. Como una página solicitada no encontrada
Información: se utiliza en la primera línea de funciones / métodos, para mostrar un procedimiento al que se ha llamado o que un paso ha ido bien, como una consulta de inserción realizada
log: información lógica, como el resultado de una sentencia if
depuración: contenidos variables relevantes para ser vistos permanentemente

Principalmente construyo sistemas de tipo de gran escala y alta disponibilidad, por lo que mi respuesta está orientada a verlo desde un punto de vista de soporte de producción; Dicho esto, asignamos aproximadamente lo siguiente:

error : el sistema está en peligro, los clientes probablemente están siendo afectados (o pronto lo estarán) y la solución probablemente requiera intervención humana. La "regla de las 2AM" se aplica aquí: si estás de guardia, ¿quieres que te despierten a las 2AM si esta condición ocurre? Si es así, regístrelo como "error".
advierta : ocurrió un evento técnico o comercial inesperado, los clientes pueden verse afectados, pero probablemente no se requiera una intervención humana inmediata. Las personas de guardia no serán llamadas inmediatamente, pero el personal de soporte querrá revisar estos problemas lo antes posible para comprender cuál es el impacto. Básicamente, cualquier problema que deba ser rastreado pero que no requiera intervención inmediata.
Información : cosas que queremos ver en un gran volumen en caso de que necesitemos analizar un problema de forma forense. Los eventos del ciclo de vida del sistema (inicio del sistema, parada) van aquí. Los eventos del ciclo de vida de la "sesión" (inicio de sesión, cierre de sesión, etc.) van aquí. También deben considerarse eventos de límite significativos (por ejemplo, llamadas a bases de datos, llamadas a API remotas). Las excepciones comerciales típicas pueden ir aquí (por ejemplo, error de inicio de sesión debido a malas credenciales). Cualquier otro evento que creas que necesitarás ver en producción a un gran volumen va aquí.
debug : casi todo lo que no hace que el corte de "información" ... cualquier mensaje que sea útil para rastrear el flujo a través del sistema y aislar los problemas, especialmente durante las fases de desarrollo y control de calidad. Usamos registros de nivel de "depuración" para la entrada / salida de la mayoría de los métodos no triviales y para marcar eventos interesantes y puntos de decisión dentro de los métodos.
rastreo : no utilizamos esto a menudo, pero esto sería para registros de volúmenes extremadamente detallados y potencialmente altos que normalmente no desea habilitar incluso durante el desarrollo normal. Los ejemplos incluyen volcar una jerarquía de objetos completa, registrar algún estado durante cada iteración de un bucle grande, etc.

Lo más importante que elegir los niveles de registro correctos es garantizar que los registros sean significativos y tengan el contexto necesario. Por ejemplo, casi siempre querrá incluir el ID de hilo en los registros para que pueda seguir un solo hilo si es necesario. También es posible que desee emplear un mecanismo para asociar información empresarial (p. Ej., ID de usuario) al hilo para que también se registre. En su mensaje de registro, querrá incluir suficiente información para garantizar que el mensaje pueda ser procesable. Un registro como "Excepción de FileNotFound capturado" no es muy útil. Un mejor mensaje es "La excepción FileNotFound se detectó al intentar abrir el archivo de configuración: /usr/local/app/somefile.txt. UserId = 12344".

También hay una serie de buenas guías de registro por ahí ... por ejemplo, aquí hay un fragmento editado de JCL (Jakarta Commons Logging) :

error - Otros errores de ejecución o condiciones inesperadas. Espere que estos sean visibles inmediatamente en una consola de estado.
advertir: uso de API en desuso, mal uso de la API, ''casi'' errores, otras situaciones de tiempo de ejecución que son indeseables o inesperadas, pero no necesariamente "incorrectas". Espere que estos sean visibles inmediatamente en una consola de estado.
Información - Eventos de tiempo de ejecución interesantes (inicio / apagado). Espere que estos sean visibles inmediatamente en una consola, así que sea conservador y mantenga al mínimo.
depuración: información detallada sobre el flujo a través del sistema. Espere que estos se escriban solo en los registros.
traza - información más detallada. Espere que estos se escriban solo en los registros.

Respondo que esto proviene de una arquitectura basada en componentes, donde una organización puede ejecutar muchos componentes que pueden depender unos de otros. Durante una falla de propagación, los niveles de registro deberían ayudar a identificar qué componentes están afectados y cuáles son una causa raíz.

ERROR : este componente ha tenido una falla y se cree que la causa es interna (cualquier excepción interna, no controlada, falla de la dependencia encapsulada ... por ejemplo, la base de datos, ejemplo de REST sería que recibió un error 4xx de una dependencia). Sácame (mantenedor de este componente) de la cama.
WARN : este componente ha tenido una falla que se cree que fue causada por un componente dependiente (el ejemplo REST sería un estado 5xx de una dependencia). Obtener los mantenedores de ese componente fuera de la cama.
INFO - Cualquier otra cosa que queramos para llegar a un operador. Si decide registrar rutas felices, le recomiendo limitar a 1 mensaje de registro por operación significativa (por ejemplo, por solicitud http entrante).

Para todos los mensajes de registro, asegúrese de registrar un contexto útil (y dé prioridad a que los mensajes sean legibles / útiles en lugar de tener "resúmenes de códigos de error")

DEBUG (y más abajo): no se debe utilizar en absoluto (y ciertamente no en producción). En desarrollo, recomendaría el uso de una combinación de TDD y depuración (cuando sea necesario) en lugar de contaminar el código con declaraciones de registro. En producción, el registro INFO anterior, combinado con otras métricas, debería ser suficiente.

Una buena forma de visualizar los niveles de registro anteriores es imaginar un conjunto de pantallas de monitoreo para cada componente. Cuando todos se ejecutan bien, están en verde, si un componente registra una ADVERTENCIA, entonces se pondrá de color naranja (ámbar), si algo registra un ERROR, entonces se pondrá de color rojo.

En el caso de un incidente, debe tener un componente (causa raíz) que se ponga en rojo y todos los componentes afectados deben estar en naranja / ámbar.