¿Cuándo debo usar Tracing vs Logger.NET, Enterprise Library, log4net o Ukadc.Diagnostics?

enterprise-library nlog (6)

Acabo de comenzar a usar log4net en VS2010 y descubrí que tiene una dependencia en System.Web ... lo que lo hace incompatible con los objetivos del marco ".NET xx Client Profile" ... Teniendo en cuenta lo que alguien aquí ha publicado acerca de Windows Update usando el El perfil del cliente como el .NET redistribuible de elección, esto significa que log4net ya no puede ser el registrador de elección si desea que su código se ejecute en la mayoría de las máquinas ...

Gracias por la información sobre otras opciones, las revisaré ...

¿Cómo puedo elegir entre el seguimiento estándar, Logger.NET, Enterprise Library, log4net o Ukadc.Diagnostics?

¿Hay una situación donde uno es más apropiado que el otro? ... ¿qué sería eso? (ASP.NET, aplicación de consola, Azure Cloud, SOHO, Enterprise ...)

¿Cuáles son los beneficios o inconvenientes?

¿Me perdí algún otro marco de registro importante?

Hay muchas preguntas similares aquí en SO:

Te perdiste varios marcos de registro de uso común. Aquí hay una lista de los marcos comúnmente utilizados, algunos de los cuales enumeró:

Registro de abstracciones:

System.Diagnostics addons:

Otro

Elmah

Un par de otras estructuras de registro de codeplex (que he visto mencionadas aquí en SO):

¿Por qué puedes elegir uno sobre el otro? Esa es una dificil. Mucho de esto es una preferencia personal. Parte de ello es la superioridad técnica (o característica).

Un inconveniente obvio de cualquier marco de registro (particularmente los de terceros) es la calidad del soporte. ¿Qué sucede si tiene un problema con log4net, NLog, Common.Logging, etc.? ¿Podrás obtener una solución de los desarrolladores de esos marcos? Esto podría no ser tremendamente importante ya que el código fuente está disponible para estos marcos. Sin embargo, es posible que prefiera NO "heredar" el árbol de origen solo para hacer una corrección o agregar una mejora. Diré que los marcos son tan extensibles, que se podrían agregar muchas mejoras a través de los puntos de extensión normales.

Si lees los enlaces que publiqué arriba, creo que es justo decir, basado únicamente en el volumen de menciones favorables, que log4net sería el claro "ganador". Se mencionará con más frecuencia como el favorito de registro histórico y lo que muchas personas elegirían utilizar en el futuro.

NLog tiene sus partidarios, simplemente no parece tener la penetración, o la conciencia de "top of mind" que log4net tiene, aunque son muy similares. Las capacidades de NLog son muy similares a log4net y tienen la ventaja adicional de haber pasado por un importante ciclo de desarrollo recientemente.

Enterprise Library es a menudo promocionada como una buena opción, pero es casi tan a menudo como una elección terrible. Tal vez parte de su reputación negativa no sea tan buena como las primeras versiones. Tal vez es mejor ahora?

System.Diagnostics se recomienda a menudo como una opción razonable con al menos tres beneficios fuertes: no es dependiente de terceros, muchos componentes de Microsoft están equipados con System.Diagnostics, es fácilmente extensible (probablemente para agregar algunas capacidades que ya están presentes "de forma gratuita" en marcos como log4net y NLog?). Si usa System.Diagnostics, creo que el consenso sería (como lo haría mi recomendación) usar objetos TraceSource en lugar de Trace.WriteLine / Debug.WriteLine.

Tenga en cuenta también que System.Diagnostics y WCF funcionan bien juntos. El tráfico de mensajes de WCF se puede registrar con System.Diagnostics y WCF también propagará la información de la actividad de System.Diagnostics (System.Diagnostics.CorrelationManager.ActivityId) a través de las llamadas de límites del servicio WCF.

No estoy tan seguro de que log4net continúe conservando su estado más favorecido. Como se ha señalado en otra parte aquí en SO, log4net no parece estar experimentando mucho desarrollo recientemente (tenga en cuenta que creo que "log4net está muerto" es una exageración) mientras que NLog 2.0 está actualmente en fase beta con la versión final esperada en el primer trimestre 2011 (Actualización: NLog 2.0 se lanzó el 17 de julio de 2011). ¿Esto convierte a NLog en una opción obviamente mejor que log4net? No lo sé, pero creo que, en términos relativos, NLog debería recibir al menos la misma consideración al elegir entre los dos y, probablemente, debería ser el supuesto favorito para el nuevo desarrollo, al menos hasta que el desarrollo de log4net muestre más signos de vida.

log4net y NLog ofrecen opciones de configuración muy flexibles. Le permiten tener una granularidad muy fina en la definición de sus declaraciones de registro (según el patrón "estándar" de definir un registrador por tipo). También permiten una fácil extensión de las bibliotecas al permitirle desarrollar sus propios objetos de "destino de registro" (Apuntadores de log4net y Objetivos de NLog) y objetos de "formato" (convertidores de patrones de log4net y NLog LayoutRenderers).

Aparte de una opción de marco de registro, algunos (¿muchos?) Abogan por aislar el código de su aplicación de una dependencia fuerte en un marco de registro particular mediante el uso de una capa de abstracción. Esto puede tomar la forma de su propia interfaz ILogger que usted implementa, quizás sobre un marco existente. En el futuro, podría cambiar los marcos implementando su ILogger en un marco diferente. O bien, podría usar DI / IoC para insertar "ILogger" en su código. Muchos marcos DI / IoC proporcionan una abstracción integrada de ILogger que se puede configurar para usar log4net, NLog o Enterprise Library o puede escribir su propia implementación de ILogger e inyectarla. ¿A quién le importa lo que es la implementación? Otra forma de aislar su código para que no tenga una dependencia fuerte en un marco de registro específico es mediante el uso de un marco de abstracción de registro existente como Common.Logging o SLF. El beneficio es que, una vez más, su aplicación no depende de un marco de trabajo de registro específico. Sin embargo, algunos dirían que acaba de cambiar una dependencia (en un marco de registro) por otro (marco de abstracción de registro).

Dos notas más sobre el registro de abstracción:

Una buena abstracción de registro debería permitirle capturar resultados de diferentes marcos de trabajo de registro en el mismo archivo de resultados. Common.Logging llama a esto "puente". Digamos que ha escrito una aplicación utilizando Common.Logging, respaldada por NLog. Ahora diga que está utilizando una biblioteca de clases de terceros que se escribe usando log4net directamente. Con un sistema de puente, puede capturar la salida de log4net (a través de un appender personalizado) y redirigirla a través de Common.Logging para que la salida de registro de la biblioteca de clases de terceros pueda verse en el contexto de la salida de registro de su aplicación.
El uso de una abstracción de registro también le permite "probar" los marcos de registro durante el desarrollo. Podría comenzar pensando que log4net es el camino a seguir, pero desea mantenerse abierto para probar NLog. Usando una abstracción de registro es relativamente fácil cambiar entre los dos. En última instancia, puede elegir el marco de registro, pero mientras tanto, ha podido escribir montañas de código que NO dependen de ningún modo de un marco de registro específico.

Otra razón por la que puede elegir un marco sobre otro es el entorno en el que trabaja. Si ya está utilizando parte de Enterprise Library, eso podría ser suficiente para empujarlo a usar el registro de Enterprise Library.

¿Qué pasa si estás desarrollando en Silverlight? Puede optar por usar algo como Clog, parte del calcio . También puede optar por utilizar NLog 2.0, que es compatible con Silverlight Y WP7.

System.Diagnostics addons (Ukadc.Diagnostics, Essential.Diagnostics). Estos no son marcos de registro per se. Más bien, representan colecciones de objetos útiles y puntos de extensión que se pueden usar con el marco existente de System.Diagnostics. Una de las mejores cosas, en mi opinión, que agrega cada uno de estos complementos es la capacidad de formatear su salida de registro, similar a cómo puede formatearlo con log4net y NLog. No he usado Essential.Diagnostics, pero he experimentado con Ukadc.Diagnostics y creo que es realmente genial. Incluso es fácil escribir tus propios "tokens de formato".

No sé si esto respondió completamente a tu pregunta (que es bastante amplia de todos modos), pero creo que hay mucha información para pensar aquí.

Mira el paquete NetLog.Logging en GitHub, es mi creación. Tiene una aplicación de monitoreo y sigue el paradigma de la API java.util.logging, porque eso es lo que me gusta usar. Tiene un bloqueo de giro para el acceso a "escritura", y el titular del bloqueo escribe todos los registros en cola, hasta un límite, antes de continuar. Esto permitirá que el registro sea una E / S basada en menos contienda y proporciona un buen compromiso.

No soy un fan de log4j o log4net. Me gusta el sistema de registro java.util.net, y por eso lo he recreado, en su mayor parte, en el proyecto github llamado NetLog en https://github.com/greggwon/NetLog/ . Siéntase libre de proporcionar comentarios. Estoy tratando de hacer algo de tiempo para poner la configuración basada en ConfigurationManager en liu de un archivo logging.properties. Con java.util.logging, siempre fue lo suficientemente fácil usar la configuración de propiedades de la línea de comandos para especificar dónde estaba la configuración de registro. Es mucho más doloroso con .net, si no hace uso del ConfigurationManager. Al proporcionar soporte para CM, se abrirá la puerta para algunas relaciones diferentes entre los registradores y los manejadores que podrían mejorar algunas cosas.

NetLog incluye un EventLogHandler que se registrará en el registro de eventos del sistema. También tiene un nivel Level.EventLog establecido en justo debajo de "warning" que le permitirá tener un "nivel" con nombre para dirigir el EventLog sin usar "WARNING" o "SEVERE". También tengo un TCPSocketHandler que te permite hacer telnet en el "registro" para que puedas tener una "cola" en Windows, sin que esté disponible un programa "cola".

Por alguna razón, System.Diagnostics no admite una forma de dirigir todos los resultados de seguimiento a un único oyente. Si desea que varias fuentes se dirijan al mismo oyente, debe enumerar explícitamente cada fuente por nombre.

En un sistema grande con muchas dependencias, es posible que no conozca todas las fuentes y probablemente no le importe. Solo desea que la salida vea lo que sucede debajo de las cubiertas. El hecho de configurar individualmente escuchas para cada fuente hace que el uso de System.Diagnostics sea mucho más difícil de usar en sistemas grandes.

log4net no solo admite un agregador (oyente) de nivel raíz, sino que también admite el registro jerárquico que le permite configurar el registro para un conjunto lógico de fuentes como un grupo. En mi opinión, esto hace que log4net sea la opción clara.

Solo para agregar algunas cosas aprendidas de la conferencia Build 2013 de Microsoft:

Log4NET bajo carga pesada ha escrito en un archivo principalmente porque este proceso es síncrono. Es posible obtener contención y tiempos de espera en ciertas condiciones. Esto se puede verificar utilizando AppDynamics o cualquier otra herramienta similar.
NLog no implementa la puesta en cola, por lo tanto, bajo carga, las llamadas IO se acumulan.
Según Microsoft, el ETW utiliza buffers de anillo del kernel que es altamente eficiente. .NET 4.5 y el marco de Event Log combinado con Semantic Logging Application Bock (AKA SLAB) hará que esto sea mucho más eficiente.