¿Hay algún problema con Log4Net?

Question

He estado utilizando Log4Net en algunos sitios web de alto tráfico durante un par de años, y no puedo decir que soy un cliente satisfecho. Por lo tanto, quería ver si alguien más tiene las mismas preocupaciones: sobrecarga

1. La CPU con RollingFileAppendor es enorme. Algunos de mis sitios web necesitan rastrear entre 5 y 10 GB por día, y cuando habilito el registro, la utilización de la CPU se duplica con creces. Me gustaría evitar la discusión de por qué se necesita tanto rastreo. Algunas aplicaciones de misión crítica tienen que rastrear cada paso de cada transacción.

2. El desplazamiento por fecha a menudo no es confiable (registra bien durante el día, pero luego arruina el archivo de registro del último día alrededor de la medianoche). Este comportamiento es inconsistente. Parece que hay muchas personas en línea que se quejan de esto y nadie parece tener una buena solución.

3. Por último, pero no menos importante, no he visto ningún lanzamiento nuevo en el sitio web de Apache durante los últimos tres años. Por lo tanto, esto comienza a verse como un proyecto de código abierto abandonado, y eso generalmente significa que es hora de pasar a un marco alternativo.

Por lo tanto, estoy considerando renunciar a Log4Net a favor de Microsoft Enterprise Library u otra cosa. ¿Hay alguien aquí que tenga los mismos problemas que yo?

Answer 1

Se podría contemplar la utilización de ASP.NET 2.0's Health Monitoring, y How To: Use Health Monitoring in ASP.NET 2.0

pero creo que va a tener problemas parecidos. Está intentando usar una herramienta de registro como una herramienta de auditoría, no exactamente para lo que fue diseñada.

"Algunas aplicaciones de misión crítica tienen que rastrear cada paso de cada transacción". - Esta es información que estaría ingresando a la base de datos como parte de una transacción. ¿Cómo podría garantizar que la información sea correcta si se ejecuta fuera de una transacción?

Answer 2

1. Sí, tiende a usar demasiada CPU. Tenía una aplicación en la que registraba ~ 15 GB/día y el uso de la CPU era bastante alto. Reduje el registro a ~ 4 GB/día, ahora el uso de la CPU no se nota en absoluto.
2. Nunca he visto este comportamiento (y he estado usando log4net desde 1.1.1 (3 años) en sitios web de alto tráfico)
3. Sí, es un poco tranquilo, pero quizás sea porque es estable, proyecto maduro. Y el desarrollo no se ha detenido por completo, puede ver en el svn repo que ha habido algunas confirmaciones recientemente. Si le preocupa esto, eche un vistazo a NLog, es un proyecto más joven y más activo.

Aquí es mi appender config para la comparación:

<appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender, log4net" > 
    <param name="File" value="log" /> 
    <param name="AppendToFile" value="true" /> 
    <rollingStyle value="Date" /> 
    <datePattern value="yyyyMMdd" /> 
    <maxSizeRollBackups value="7" /> 
    <layout type="log4net.Layout.PatternLayout, log4net"> 
     <param name="ConversionPattern" value="%d [%t] %-5p %c [%x] - %m%n" /> 
    </layout> 
</appender> 

Answer 3

Puede ser que no es su caso, pero creo que con tales volúmenes de datos de registro que debe utilizar el sistema de gestión de registros que tiene cero o un efecto mínimo en su aplicación real durante el tiempo de ejecución. Rodar y administrar gigabytes de registro es bastante incómodo a menos que toda la aplicación lo haga. Otro punto: he escuchado muchas quejas de los usuarios del registro de entlib, particularmente con respecto al rendimiento. Verificaría cómo funcionaría con sus volúmenes de datos antes de cambiar a él. Pero incluso si lo encuentra mejor que log4net, creo que todavía administrará enormes archivos de registro usted mismo.

Answer 4

Hasta ahora, me inclino a culpar a todo por la función de rodadura basada en la fecha. Intenté cambiarlo para que funcione en algunos servidores, y ya no veo pérdidas de datos. Por supuesto, esta no es una solución bonita porque ya no tengo un archivo de rastreo por día. Además, el desplazamiento basado en el tamaño parece tener un error que hace que el archivo se desplace demasiado pronto o demasiado tarde. Pero esto no es tan doloroso como el problema original ...

Answer 5

Por la cuestión de rendimiento, lo mejor de log4net es que siempre se puede perfilar para ver dónde está embotellado el uso de la aplicación de log4net y: 1) Tackle la solución usted mismo o 2) Encuentre un marco de registro que no tenga ese cuello de botella.

no puedo evitar demasiado sin saber que su aplicación, pero desde una mirada superficial a la fuente log4net me di cuenta de que la función NextCheckDate() está siendo llamado en CADA void Append(LoggingEvent loggingEvent). He incluido una parte de la fuente de NextCheckDate a continuación y definitivamente podría imaginarse esto causando problemas de rendimiento en escenarios de registro de gran volumen.

protected DateTime NextCheckDate(DateTime currentDateTime, RollPoint rollPoint){ 
// Local variable to work on (this does not look very efficient) 
DateTime current = currentDateTime; 

// Do different things depending on what the type of roll point we are going for is 
switch(rollPoint) 
{ 
    case RollPoint.TopOfMinute: 
     current = current.AddMilliseconds(-current.Millisecond); 
     current = current.AddSeconds(-current.Second); 
     current = current.AddMinutes(1); 
     break; 

    case RollPoint.TopOfDay: 
     current = current.AddMilliseconds(-current.Millisecond); 
     current = current.AddSeconds(-current.Second); 
     current = current.AddMinutes(-current.Minute); 
     current = current.AddHours(-current.Hour); 
     current = current.AddDays(1); 
     break; 

    case RollPoint.TopOfMonth: 
     current = current.AddMilliseconds(-current.Millisecond); 
     current = current.AddSeconds(-current.Second); 
     current = current.AddMinutes(-current.Minute); 
     current = current.AddHours(-current.Hour); 
     current = current.AddMonths(1); 
     break; 
}  
return current;} 

una versión optimizada para su aplicación, probablemente en caché la próxima vez vuelco de antemano y sólo hacer una única comparación para cada Append

Answer 6

lo tanto, estoy considerando la posibilidad de renunciar a Log4net a favor de la Microsoft Enterprise Library o algo más.

Para una comparación de los marcos de registro alternativas que puede tener en cuenta, ver http://essentialdiagnostics.codeplex.com/wikipage?title=Comparison

En él se compara System.Diagnostics de .NET Framework (construido en capacidades), log4net, Nlog y Enterprise Library, incluyendo una comparación de rendimiento .

Cada uno tiene fortalezas y debilidades, pero EntLib lo hace particularmente malo en la comparación de rendimiento y, en términos de características, a veces tiene menos que el .NET Framework System.Diagnostics incorporado.

Si está particularmente preocupado por el rendimiento, entonces log4net gana ligeramente con .NET Framework System.Diagnostics similar.

NLog tiene muy poca sobrecarga cuando no se registra (es decir, simplemente lo deja en el código), más rápido que log4net o System.Diagnostics, pero a medida que aumenta el volumen de registro comienza a quedarse atrás.

Para el registro de alto rendimiento usando System.Diagnostics, con rotación de registro (incluido el circular), eche un vistazo al EventSchemaTraceListener, que recientemente blogged about, pero el soporte de herramientas para ver los registros (que están en formato XML) isn muy bien

Le sugiero que establezca algunas pruebas de rendimiento si está preocupado. Para la comparación mencionada anteriormente, el código fuente de la comparación de rendimiento está disponible en el proyecto Essential Diagnostics, por lo que puede ejecutarlo usted mismo, pero es posible que desee adaptarlo a su situación.