¿Por qué podría Log4net entradas van "perdido" en algunos oyentes

Question

Esto realmente me ha rascándome la cabeza ....

He estado usando log4net (actualmente la versión 1.2.10) en una aplicación desde hace algún tiempo. Mientras agregaba una nueva opción a la aplicación, noté que a pesar de que el apilador de la consola no estaba viendo los métodos log4net Debug, Error, etc. que llamaban a los elementos de ese origen de registro.

Después de haber comprobado lo obvio (como asegurarse de que no haya filtrado), noté algo extraño. Si tengo más de un appender (por ejemplo, un apéndice de archivo de registro y un appender UDP), los appenders a veces verán diferentes subconjuntos de los mensajes de registro. El subconjunto que ven parece ser aleatorio, pero normalmente cuando se produce el problema no pueden ver todos los mensajes de una fuente de registro determinada.

¿Por qué podría estar sucediendo esto, y qué puedo hacer al respecto, ya que la pérdida de mensajes significa que no se puede confiar en que el archivo de registro muestre una imagen precisa de los fallos remotos?

[a la información adicional añadido decimonovena Ene, 2010]

finalmente tomó una buena mirada en el objeto ILOG conseguir pasar de nuevo en respuesta a la llamada

LogManager.GetLogger(typeof (MyTypeHere)); 

En algunas ocasiones, me Estoy obteniendo un objeto ILog con Depuración, Información, Advertencia, Error, etc. configurado en falso. En otras ocasiones, el objeto ILog los ha configurado correctamente en verdadero. Como mi código no hace nada para manipular esos indicadores, en las ocasiones en que se pasa mi código, los mensajes de objeto ILog "deshabilitados" de mi código (comprensiblemente) no se propagan en absoluto.

Todavía no puedo explicar la aparente discrepancia entre los dos apéndices.

Answer 1

Regularmente utilizamos el archivo de registro, la consola y los agregados smtp juntos y parece que no tenemos estos problemas. Bajo ciertas condiciones, algunos apéndices pueden perder mensajes debido a su naturaleza inherente. Por ejemplo, no se garantiza que el appender UDP, debido al mecanismo de transporte, transmita todos los mensajes. Lo mismo sucede con el apilador SMTP. Si está utilizando un archivo de registro común pero registra desde varios procesos, a veces el archivo está bloqueado por otro proceso (esto generalmente arroja una excepción, pero puede estar atrapado en algún lugar de su código), así que asegúrese de establecer la propiedad de Bloqueo mínimo en eso. Además, los appenders pueden almacenarse en búfer, por lo que si se produce un bloqueo del proceso, es posible que log4net no tenga la posibilidad de eliminar los datos almacenados en el búfer.

Al final, los apéndices más confiables son aquellos que se registran localmente, como el archivo y los apéndices del registro de eventos, pero luego tiene que cosechar todos los registros. Si desea iniciar sesión centralmente, es posible que desee considerar el inicio de sesión en una base de datos o en una cola de mensajes.

Answer 2

¿Entiendo correctamente que algunos mensajes que normalmente se registran con éxito repentinamente dejan de aparecer (se registran) en algún momento? Si ese es el caso, sugiero activar el registro interno de log4net. Alternativamente, depure el problema con el código log4net (con su problema, le sugiero que rompa el método CallAppenders en la clase Logger. Le dirá qué appenders serán llamados para un evento de registro).

Si algunos mensajes no se están registrando consistentemente, entonces vería la configuración de log4net. Verifique que se hayan establecido los niveles/umbrales y, lo que es más importante, si está utilizando registradores verifique sus nombres y asegúrese de que el prefijo de lo que ingrese en la llamada LogManager.GetLogger (...) coincida con los registradores de nombres en su configuración.

Duplico lo que dijo jvilalta. He estado usando log4net durante años con muchos tipos de appenders y no he visto una situación en la que falte un mensaje solo de algunos de los appenders pero no de todos.

Answer 3

Sé que esto es antiguo, pero he tenido esto en las aplicaciones asp.net mvc recientemente y fue muy frustrante rastrear. Parece suceder en métodos que usan el atributo ValidateInput(false).

Supongo que al utilizar este atributo se salta la inicialización de algunos datos a los que log4net intenta acceder durante el registro. He descubierto que añadiendo lo siguiente a mi web.config solucionó el problema:

<httpRuntime requestValidationMode="2.0" /> 

Por supuesto que tiene otros efectos secundarios (no relacionados con la explotación forestal).