Prácticas recomendadas de prioridad de registro de Commons

Question

Esto puede ser una pregunta puramente subjetiva (si ninguna organización ha intentado estandarizar esto), pero mi equipo tiene problemas con esto más de lo que podría pensar.

Usamos Apache Commons Logging como nuestra interfaz de registro y, a menudo, el uso de la prioridad no es constante en todo nuestro equipo de desarrollo. Por ejemplo, algunos desarrolladores registran cualquier excepción detectada como fatal (log.fatal (mensaje)) aunque el flujo pueda controlar el error, mientras que otros solo se registran como fatales cuando algo causa que el programa deje de ejecutarse necesariamente por cualquier razón.

Me gustaría saber cómo otros equipos definen cada prioridad. ¿Alguien trabaja en una empresa que explícitamente intenta definir las mejores prácticas para esto? ¿Ha influido Jakarta en esto?

Mi objetivo sería enviar una recomendación simple para cada prioridad a todo mi equipo para que podamos manejar de manera más efectiva nuestro registro de aplicaciones difíciles de manejar de manera consistente.

Answer 1

Esto es lo que usamos (y yo diría que muchos otros también):

• grave: los errores que ponen en peligro la coherencia del sistema y podrían requerir un cierre inmediato/reinicio - muy rara vez se utiliza manualmente
• ERROR: excepciones que no deberían arrojarse y que representan un error en el sistema (normalmente todas las excepciones que no se alcanzan hasta cierto punto)
• ADVERTENCIA: excepciones que pueden ocurrir pero se consideran o situaciones que pueden implicar error de lógica/uso: decidimos si rastrear esos o no
• INFORMACIÓN: lo que necesita tener en el registro, p. lo que los usuarios hacen actualmente (en nuestro caso de aplicaciones web: ¿qué página que el usuario está navegando hacia etc.)
• DEBUG: depuración sólo los mensajes como horarios, etc, en general, se ha desactivado en los registros
• TRACE: no usamos eso, es posible utilizarlo para información de depuración aún más específico

en algunos casos partimos de mensajes de registro como el error, con el fin de obtener la notificación cuando ocurre algo que normalmente no gustaría a pasar. Más tarde, si decidimos que no se puede eliminar el origen de ese error, lo gestionamos y cambiamos el nivel de registro a WARN.

Tenga en cuenta que nuestros sistemas de prueba y producción están configurados para enviar un correo electrónico para FATAL y ERROR. Por lo tanto, no es necesario que verifiquemos manualmente los archivos de registro, sino que solo debemos verificar una bandeja de entrada de correo electrónico.

Espero que ayude.

Editar: ¿ya has mirado el Apache Commons Logging best pratices?

Answer 2

Siempre he usado esto como una guía; Yo uso Log4J más de los Comunes de registro, pero esto aún puede ser útil:

DEBUG - para obtener información de nivel de depuración de verdad; no se verá en producción o producto enviado, ya que INFO será el nivel mínimo; bueno para capturar tiempos, cantidad de ocurrencias de eventos, etc.

INFO - nivel mínimo para producción/uso enviado; registrar datos que puedan ser útiles en investigaciones forenses y confirmar los resultados exitosos ("999 artículos almacenados en DB OK"); toda la información que aquí debe ser tal que estaría bien con los usuarios finales/clientes verlo y enviarlo, si es necesario

WARN (sin secretos, sin malas palabras!) - no un nivel de error como tal, sino útil para saber que el sistema puede estar entrando en territorio peligroso, por ejemplo lógica de negocios como "número de productos pedidos < 0" que sugiere un error en alguna parte, pero no es una excepción del sistema; Tiendo a no utilizar que sea mucho para ser honesto, encontrar cosas tienden a ser ataques más naturales a la información o ERROR

ERROR - usar esto para excepciones (a menos que haya una buena razón para reducir al WARN o INFO); registre registros de pila completos junto con valores variables importantes sin los cuales el diagnóstico es imposible; utilizar sólo para los errores de aplicación/sistema, no está mal circunstancias lógica de negocio

FATAL - sólo la usamos para un error de tan alta gravedad que, literalmente, impide la aplicación desde el inicio/continua

Además - revisar su registro a menudo, con los niveles DEBUG e INFO activos, quiere poder seguir una buena narrativa, con eventos destacados fáciles de encontrar y asegurarse de que no está haciendo nada demasiado detallado que le resta legibilidad.

También asegúrese de usar un patrón que conduzca a columnas ordenadas para cosas como sellos de tiempo, clases fuente y gravedad; de nuevo, ayuda a la legibilidad masivamente.

Answer 3

Mi opinión

• Fatal: El programa se encuentra en un estado que no puede ser manipulado y debe ser terminada (de forma automática o por el usuario).
• Error: El funcionamiento del programa falló de manera detectable por el usuario (los cambios no se guardaron/no se pudo leer un archivo), pero el programa aún puede funcionar (intente cargar otro archivo).
• Advertencia: Algo no fue tan planeado, pero el usuario no se dio cuenta (un servidor no respondió a un ping, tal vez cuando se necesita que el servidor que causará un error/mortal)
• Info: Acciones de usuario/importante acciones del programa (archivo cargado, copia de seguridad automática almacenada).
• Depuración: información de seguimiento. ¿Qué parte de la ejecución del programa, que son los valores de los parámetros

Answer 4

Esto es lo que mi compañía recomienda:

TRACE - Mensajes probablemente sólo es útil durante el ciclo de desarrollo, y posiblemente generados demasiado con frecuencia para un uso adecuado en la producción. Por ejemplo, si estuviera registrando valores intermedios en un bucle interno, usaría TRACE.

DEBUG - Mensajes utilizados para registrar varios pasos en el funcionamiento normal del servidor. Por lo general, estos se dirigirán a los desarrolladores en lugar de al personal de operaciones.

INFO - Mensajes de naturaleza positiva o neutral que cabría esperar en un entorno de producción. Debe ser significativo para el personal de operaciones.

WARN - Mensajes que indican una condición que posiblemente pone en peligro la capacidad del servidor para responder a las solicitudes de manera precisa y oportuna.

ERROR - Mensajes que indican un comportamiento o condición inesperados.

FATAL - Mensajes que indican un comportamiento o condición inesperada que hace que la ejecución continua del proceso de solicitud sea imposible o peligrosa.

Esperamos que los registros en producción se establezcan en INFO, y esperamos que sean leídos por personas que no sean los desarrolladores. Estilo de los mensajes de registro es un conjunto la otra conversación ...

Answer 5

estoy usando un enfoque más simple:

• DEBUG: Se apaga en la producción, por lo que se utiliza principalmente por el desarrollador para registrar ciertas consultas , horarios, valores de parámetros, etc.

• INFO: registra todo para que sepa en retrospectiva todo para explicar cómo se calcularon los resultados y para que pueda corregir los errores

• ERROR: Todo lo que necesita de alguien (Programador/operaciones) atención

No consumo WARN, porque nadie nunca filtra todos los archivos de registro de mensajes WARN. Si es importante, entonces es ERROR (y alguien debe preocuparse por ello), si no, es INFO (y nadie está interesado en él hasta que haya un problema). Lo mismo para FATAL.

Yo tampoco uso TRACE. Todo lo que necesito saber durante el desarrollo es DEBUG.

Answer 6

Si está buscando una recomendación simple que sea compatible con la industria, ¿por qué no solo mira la implementación/documentación simple de la industria?

se utiliza una API logback/log4j como logging level guide => lo cual hace que sea sencillo/documentado/respaldada por la industria:

• Nivel TODO tiene el rango más bajo posible y está destinado a encender todos los registros

• Nivel DEBUG designa eventos informativos detallados que son más útiles para depurar una aplicación.

• Nivel ERROR designa eventos de error que aún pueden permitir que la aplicación continúe ejecutándose.

• Nivel FATAL designa eventos de error muy graves que presumiblemente conducirán a la aplicación a abortar.

• Nivel INFO designa los mensajes informativos que destacan el progreso de la aplicación en el nivel de grano grueso.

• Nivel OFF tiene el rango más alto posible y está destinado a desactivar el registro.

• Nivel TRACE designa eventos informativos de grano más fino que el de depuración

• Nivel advierten designa situaciones potencialmente dañinos.