log4j -adaptive log level- feature

Question

No quiero reinventar la rueda, así que me pregunto si algún sistema de registro ya admite algo así como lo que estoy proponiendo.

Antecedentes: Estoy trabajando en un sistema extremadamente grande donde decenas de miles de usuarios acceden a los servidores en un momento dado. Hay muchas infraestructuras circundantes involucradas, por lo que puede imaginarse cómo se investigan los errores que ocurren con tan solo leer los registros en dicho ecosistema.

Nuestro sistema utiliza log4j.

La raíz principal del problema era que los implementadores originales eran bastante 'económicos', para decirlo suavemente, cuando se encontraba con un error desconocido. Claro, el nivel de DEPURACIÓN sería útil en la mayoría de los casos, pero por supuesto, los registros de producción están configurados en el nivel de ERROR solamente :(

Ahora intento hacer un mundo mejor para nuestros hijos y quiero expandir el sistema de registro a ser más 'benignos' sobre el nivel de registro

lo que tengo en mente es la siguiente:.
Dado que los registros de nivel de depuración de los alrededores (N antes y M después de que el registro de errores) podría contener datos importantes, ¿por qué no baje el nivel de registro del sistema alrededor del ERROR.

Mi idea:

1. asumamos conjunto de nivel de registro de errores para el sistema
2. uso algún tipo de búfer de registro de vuelco de tamaño X. Cada registro va allí y se reenvía a log4j.
3. Cuando tampón consigue registrar un error que puede también salida el contexto de n mensajes siguiente de registro anteriores y M por cualquiera de
   1. aumentar artificialmente el nivel de registro de error de estado (y observando que, por supuesto) o
   2. simplemente ingrese ese contexto a través de un ERROR inyectada ingrese

Hay algunos problemas para trabajar fuera, pero, en general, que podría funcionar.

¿Alguna idea?

Saludos

Answer 1

BufferingForwardingAppender podría ser una solución. La documentación asociada con el ejemplo indica "Esto significa que los eventos solo se entregarán cuando se registra un mensaje con nivel de WARN o nivel superior. También se entregarán hasta 512 (BufferSize) mensajes anteriores de cualquier nivel para proporcionar información de contexto. Los mensajes no enviados serán descartados ".

Ver: http://logging.apache.org/log4net/release/config-examples.html#buffering

Para aplicaciones web ocupados esto probablemente no es el mejor enfoque. En la mayoría de los casos, está interesado en los mensajes de registro asociados con la sesión o solicitud específica que causó el ERROR. Dado que una solicitud generalmente se maneja con un único hilo, esto se puede lograr manteniendo un búfer "por hilo" para los mensajes de registro.Al agregar un filtro de servlet uno puede borrar el búfer cada vez que el servidor comienza a procesar una nueva solicitud del cliente.

O incluso mejor sería mantener (si el uso de memoria no es un problema) los búferes por sesión HTTPS. De esta forma podría obtener la información de depuración no solo para la solicitud que causó problemas, sino también para una solicitud previa (para ayudar a averiguar qué estaba haciendo el usuario)