¿Cómo elijo entre el rastreo estándar, Logger.NET, Enterprise Library, log4net o Ukadc.Diagnostics?¿Cuándo debería usar Tracing vs Logger.NET, Enterprise Library, log4net o Ukadc.Diagnostics?
¿Hay una situación en la que 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?
¿Echaba de menos cualquier otro framework de registro importante?
Hay muchas preguntas similares aquí en SO:
Olvidó varios marcos de registro de uso general. Aquí está una lista de los marcos de uso común, algunas de las cuales se enumeran a continuación:
de registro:
sistema.Diagnóstico de complementos:
Otros
Un par de otros marcos de registro de CodePlex (que he visto que se ha mencionado Re sobre SO):
¿Por qué puede elegir uno sobre el otro? Esa es una dificil. Mucho de esto es preferencia personal. Parte de esto es superioridad técnica (o característica).
Una desventaja obvia de cualquier marco de registro (especialmente 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 puede 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 realizar 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 leyó los enlaces que publiqué anteriormente, creo que es justo decir, basándose ú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 mucha gente elegiría usar de ahora en adelante.
NLog tiene sus partidarios, simplemente no parece tener la penetración, o conocimiento "de la mente" que lo hace log4net, a pesar de que son muy similares. Las capacidades de NLog son muy similares a log4net y tiene la ventaja adicional de haber pasado recientemente por un ciclo de desarrollo significativo.
Enterprise Library a menudo se promociona como una buena opción, pero es casi tan a menudo como una opción terrible. Tal vez parte de su reputación negativa es tal vez no tan buenas versiones anteriores? Tal vez es mejor ahora?
System.Diagnostics a menudo se recomienda como una opción razonable con al menos tres ventajas fuertes: ninguna dependencia de terceros, muchos componentes de Microsoft están equipados con System.Diagnostics, es fácilmente extensible (presumiblemente para agregar algunas capacidades que ya están presentes "gratis" en marcos como log4net y NLog?). Si utiliza System.Diagnostics, creo que el consenso sería (como recomendaría) utilizar objetos TraceSource en lugar de Trace.WriteLine/Debug.WriteLine.
Nótese también que System.Diagnostics y WCF trabajan bien juntos. El tráfico de mensajes WCF se puede registrar con System.Diagnostics y WCF también propagará la información de actividad de System.Diagnostics (System.Diagnostics.CorrelationManager.ActivityId) a través de las llamadas de límite del servicio WCF.
no estoy tan seguro de que log4net debe seguir manteniendo su estatus más favorecida. As has been noted elsewhere here on SO, log4net does not seem to be undergoing a lot of development recently (nota que pienso "log4net está muerto" es una exageración), mientras que Nlog 2.0 es actualmente en beta con la versión final se espera en el Q1 de 2011 (Actualización: Nlog 2.0 was released el 17 jul, 2011).¿Esto hace que NLog sea obviamente una opción 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 log4net muestre más signos de vida.
log4net y NLog ofrecen opciones de configuración muy flexibles. Le permiten tener granularidad muy fina en la definición de sus declaraciones de registro (por el patrón "estándar" de definición de un registrador por tipo). También permiten la extensión fácil de las bibliotecas permitiéndole desarrollar sus propios objetos de "destino de registro" (Log4net Appenders y NLog Targets) y objetos de "formateo" (log4net pattern converters 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 fuerte dependencia en un marco de registro particular mediante el uso de una capa de abstracción. Esto puede tomar la forma de su propia interfaz de ILogger que implementa, tal vez encima de 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 inyectar "ILogger" en su código. Muchos marcos DI/IoC proporcionan una abstracción de ILogger incorporada que puede configurarse para usar log4net, NLog o Enterprise Library o puede escribir su propia implementación de ILogger e inyectar eso). A quién le importa cuál es la implementación? Otra forma de aislar su código de tener una dependencia dura en un marco de registro específico es a través del 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 registro específico. Sin embargo, algunos dirían que acaba de cambiar una dependencia (en un marco de registro) por otra (marco de abstracción de registro).
Otras dos notas sobre la abstracción de registro:
Una buena abstracción de registro debe permitir que le permite capturar la salida de diferentes marcos de registro en el mismo archivo de salida. Common.Logging llama a esto "puente". Digamos que ha escrito una aplicación usando Common.Logging, respaldado por NLog. Ahora diga que está usando una biblioteca de clases de terceros que está escrita usando log4net directamente. Con un sistema de puente, puede capturar la salida log4net (a través de un appender personalizado) y redirigirla a Common.Logging para que la salida de registro de la biblioteca de clases de terceros se pueda ver 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 la unidad" de los marcos de registro durante el desarrollo. Puede comenzar pensando que log4net es ese camino por recorrer, pero quiere dejarse abierto para intentar NLog. Usando una abstracción de registro es relativamente fácil cambiar entre los dos. En última instancia, puede elegir qué estructura de registro, pero, mientras tanto, ha podido escribir montañas de código que NO es dependiente de ninguna manera en 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 la biblioteca de Enterprise, eso podría ser suficiente para empujarlo a utilizar el registro de Enterprise Library.
¿Qué sucede si se está desarrollando en Silverlight? Puede optar por usar algo como Clog - part of Calcium. También puede optar por usar 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 System.Diagnostics existente. Una de las mejores cosas, en mi opinión, que cada uno de estos complementos agrega 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 sus propios "tokens de formateo".
No sé si esto ha respondido completamente a su pregunta (que de todos modos es bastante amplia), pero creo que hay mucho que pensar aquí.
Acabo de empezar a usar log4net en VS2010 y descubrí que tiene una dependencia en System.Web ... lo que la hace incompatible con los objetivos del marco ".NET xx Client Profile ... Teniendo en cuenta lo que alguien ha publicado aquí Actualización de Windows utilizando el perfil de cliente como .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 estaré revisando ...
Gracias Toadflakz por la punta – LamonteCristo
No soy seguidor de log4j o log4net. Me gusta el recurso de registro java.util.net, así que lo he recreado, en su mayor parte, en el proyecto github llamado NetLog al https://github.com/greggwon/NetLog/. Siéntase libre de dar su opinión. Estoy tratando de hacer un poco de tiempo para poner en configuración configurada en ConfigurationManager en liu de un archivo logging.properties. Con java.util.logging, siempre fue bastante fácil usar la configuración de la propiedad de la línea de comando para especificar dónde estaba la configuración del registro. Es mucho más doloroso con .net, si no hace uso de ConfigurationManager. Proporcionar soporte para CM, abrirá la puerta a algunas relaciones diferentes entre los madereros y los manipuladores que pueden mejorar algunas cosas.
NetLog incluye un EventLogHandler que se registrará en el registro de eventos del sistema. También tiene un nivel Level.EventLog configurado justo debajo de "warning" que le permitirá tener un "nivel" con nombre para apuntar a EventLog sin usar "WARNING" o "SEVERE". También tengo un TCPSocketHandler que te permite acceder por telnet al "registro" para que puedas tener una "cola" en Windows, sin que esté disponible un programa de "cola".
sólo para añadir algunas cosas aprendidas de la conferencia Build 2013 de Microsoft:
Log4net bajo carga pesada ha escrito a un archivo sobre todo 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 cola, por lo tanto, bajo carga, las llamadas IO se acumulan.
De acuerdo con Microsoft, ETW utiliza buffers de anillo kernel que es altamente eficiente. .NET 4.5 y el marco de registro de eventos combinados con Semantic Logging Application Bock (AKA SLAB) harán que esto sea mucho más eficiente.
Por favor cite tus ejemplos. –
@ DanEsparza Creo que el enlace en mi pregunta tiene todas las citas. – LamonteCristo
Estaba buscando enlaces para "Es posible obtener contención y tiempos de espera en ciertas condiciones", "NLog no implementa cola, así que bajo carga, las llamadas IO se acumulan", y "Según Microsoft, ETW usa kernel ring buffers que es altamente eficiente " –
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 acceder a "escritura", y el titular de la cerradura escribe todos los registros en cola, hasta un límite, antes de continuar. Esto permitirá que el registro sea menos E/S basado en contención y proporciona un buen compromiso.
Por alguna razón, System.Diagnostics no es compatible con una forma de dirigir todos los resultados de rastreo a un solo 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, puede que no conozca todas las fuentes y probablemente no le importe. Solo quiere que la salida vea lo que sucede bajo las sábanas.Tener que configurar oyentes individuales para cada fuente hace que el uso de System.Diagnostics sea mucho más difícil de usar en sistemas grandes.
log4net no solo es compatible con un apéndice de raíz (listener), sino que también admite el registro jerárquico que le permite configurar el registro para un conjunto lógico de orígenes como un grupo. En mi opinión, esto hace que log4net sea la elección más clara.
+1 millón, ¡Gracias por su respuesta que parece provenir de la experiencia y de una amplia variedad de conocimientos! – LamonteCristo
Quería votar para cerrar esta pregunta, porque esto se ha preguntado cientos de veces aquí en SO. Sin embargo, tu respuesta es extremadamente buena. Realmente agrega valor a las respuestas ya dadas aquí en SO. Por esa razón, no hay voto para cerrar, pero un +1 para ti. – Steven
@Steven - ¡Gracias por las amables palabras! – wageoghe