Niveles de registro - Logback - regla general para asignar niveles de registro

Estoy usando logback en mi proyecto actual.

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

Estoy buscando una regla general 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 el nivel de información. O si se usa un socket, si su identificación específica se registra en el nivel de depuración o en el nivel de rastreo.

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

Principalmente construyo sistemas a gran escala y de alta disponibilidad, por lo que mi respuesta está sesgada a mirarlo 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 se vean afectados (o pronto lo serán) y la solución probablemente requiera intervención humana. La "regla de las 2AM" se aplica aquí: si está de guardia, ¿quiere que lo despierten a las 2AM si ocurre esta condición? En caso afirmativo, regístrelo como "error".

• advertir : ocurrió un evento técnico o comercial inesperado, los clientes pueden verse afectados, pero probablemente no se requiere intervención humana inmediata. Las personas de guardia no serán llamadas de inmediato, 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.

• info : cosas que queremos ver a gran volumen en caso de que necesitemos analizar forense un problema. Los eventos del ciclo de vida del sistema (inicio del sistema, parada) van aquí Los eventos del ciclo de vida de "sesión" (inicio de sesión, cierre de sesión, etc.) van aquí. También se deben considerar eventos de límite significativos (por ejemplo, llamadas a la base de datos, llamadas API remotas). Las excepciones comerciales típicas pueden ir aquí (por ejemplo, error de inicio de sesión debido a credenciales incorrectas). Cualquier otro evento que creas que necesitarás ver en producción a gran volumen va aquí.

• depuración : casi todo lo que no corta la "información" ... cualquier mensaje que sea útil para rastrear el flujo a través del sistema y aislar problemas, especialmente durante las fases de desarrollo y control de calidad. Utilizamos 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 usamos esto a menudo, pero esto sería para registros de volumen 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.

Tan importante o 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ás incluir la ID del hilo en los registros para que puedas seguir un solo hilo si es necesario. También es posible que desee emplear un mecanismo para asociar información comercial (por ejemplo, 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 detectada" no es muy útil. Un mensaje mejor es "Se ha detectado la excepción FileNotFound 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 (Registro de Yakarta Commons) :

• error: otros errores de tiempo de ejecución o condiciones inesperadas. Espere que estos sean visibles de inmediato en una consola de estado.
• advertir: uso de API en desuso, mal uso de API, 'casi' errores, otras situaciones de tiempo de ejecución que son indeseables o inesperadas, pero no necesariamente "incorrectas". Espere que estos sean visibles de inmediato en una consola de estado.
• info: eventos de tiempo de ejecución interesantes (inicio / apagado). Espere que estos sean visibles de inmediato en una consola, así que sea conservador y manténgalo 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.
• rastro: información más detallada. Espere que estos se escriban solo en los registros.

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

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

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

Por 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 mesa dice que sí.

de la documentación de logback :

De una manera más gráfica, así es como 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 resultante 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 .

Respondo esto desde una arquitectura basada en componentes, donde una organización puede estar ejecutando 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 la 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 dependencia encapsulada ... por ejemplo, base de datos, ejemplo REST si hubiera recibido 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 es causada por un componente dependiente (el ejemplo REST sería un estado 5xx de una dependencia). Saque a los mantenedores de ESE componente de la cama.

• INFORMACIÓN - Cualquier otra cosa que queramos 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 el contexto útil (y priorice hacer que los mensajes sean legibles / útiles para los humanos en lugar de tener montones de "códigos de error")

• DEPURACIÓN (y a continuación): no debe usarse en absoluto (y ciertamente no en producción). En desarrollo, recomendaría usar una combinación de TDD y depuración (cuando sea necesario) en lugar de código contaminante con declaraciones de registro. En producción, el registro INFO anterior, combinado con otras métricas debería ser suficiente.

Una buena manera de visualizar los niveles de registro anteriores es imaginar un conjunto de pantallas de monitoreo para cada componente. Cuando todo funciona bien, son verdes, si un componente registra una ADVERTENCIA, se volverá naranja (ámbar) si algo registra un ERROR y luego se pondrá rojo.

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

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

1. Error: errores lógicos críticos en la aplicación, como un tiempo de espera de conexión de la base de datos. Cosas que requieren una corrección de errores en un futuro próximo
2. Advertencia: problemas que no se rompen, pero cosas a las que prestar atención. Al igual que una página solicitada no encontrada
3. Información: se utiliza en la primera línea de funciones / métodos, para mostrar un procedimiento que se ha llamado o un paso que salió bien, como una consulta de inserción realizada
4. log: información lógica, como el resultado de una declaración if
5. depuración: contenido variable relevante para ser visto permanentemente