.net - System.Diagnostics.Debug namespace vs Otras soluciones de registro(log4net, MS Enterprise Library, etc.)

enterprise-library (4)

Desde un punto de vista del desarrollador, las preocupaciones como el registro, similar a orm, no deben ser escritas a mano. Hay un montón de buenas bibliotecas sólidas de terceros. Claro que a veces hay un poco de trabajo de configuración por hacer, pero si lo comparamos con las soluciones propias, es solo una gota en el agua.

Mi preferencia personal es log4net pero depende de sus necesidades. Mi mejor consejo es echar un vistazo a la documentación de soluciones como log4net o EntLib Logging Application Block y tomar una decisión sobre lo que es mejor para usted.

Actualmente estoy investigando varias posibilidades de registro para proyectos .net y no puedo decidir entre System.Diagnostics.Debug / Trace y bibliotecas de terceros como log4net, MS Enterprise Library, NLog, etc.
En este momento he descubierto esto:

System.Diagnostics es bastante difícil de configurar y usar, ya que necesita configurar explícitamente todos los oyentes, filtros, fuentes, etc. Parece que también le falta la inserción masiva en la base de datos (piense en escribir 100''000 entradas de registro cada una con Su propia inserción, horrible, ¿no?). Pero algunas personas consideran que es "genial" no usar bibliotecas adicionales para algo tan "rudimentario" como el registro (por supuesto, en algún momento, tiene sentido reducir la cantidad de bibliotecas de terceros en las que se basa su proyecto, pero no esta vez, supongo)
Los terceros son mucho más poderosos, a menudo más rápidos, mucho más fáciles de usar, pero a veces la configuración también puede ser dolorosa y, a menudo, estas libretas son menos confiables (como la misteriosa detención repentina del registro por parte de EntLib, etc.)
¿Qué hay de Common.Logging? ¿vale la pena intentarlo (ya que, como he escuchado, ofrece varios marcos de inicio de sesión de conexión y actúa como una interfaz entre la aplicación y la biblioteca deseada)?

¡Estaría muy agradecido si alguien pudiera indicarme la dirección correcta o corregir (o agregar algo) a la comparación que he dado anteriormente! Tal vez si me animas a usar terceros, podrías recomendar a alguien en particular (teniendo en cuenta que nuestras aplicaciones probablemente no necesiten ningún material sofisticado como UDP, archivos rodantes, etc.) simplemente archivos, correo electrónico, DB y registro de eventos)?
¡Gracias por adelantado!

El registro y el rastreo son preocupaciones diferentes. El registro se refiere a la retroalimentación operativa. El rastreo (incluido el proporcionado por los métodos de depuración) corresponde al desarrollo y las pruebas. El código de seguimiento no debe compilarse en los ensamblados de lanzamiento. Las clases Trace y Debug logran esto con las anotaciones del compilador (ConditionalAttribute). Dicho código debe optimizarse para recopilar gran cantidad de datos, no para el rendimiento. Por otro lado, el registro operativo debe optimizarse para el rendimiento y para una variedad más amplia de mecanismos de almacenamiento, según lo requiera el equipo de administración de sistemas / operaciones.

Por lo tanto, recomiendo usar tanto Trace / Debug para el desarrollo como paquetes de registro más robustos para las operaciones.

Puede encontrar mucha información acerca de log4net y NLog aquí en en Google en general.

También puedes encontrar mucha información sobre los diagnósticos del sistema. Una cosa a tener en cuenta acerca de System.Diagnostics, creo que encontrará muchas referencias aquí en sobre el uso de Debug.Write / WriteLine y Trace.Write / WriteLine. Una manera posiblemente "mejor" es utilizar TraceSources. TraceSources es análogo a los registradores en log4net y NLog. TraceSources le permite tener un mayor grado de granularidad en sus mensajes de registro, lo que facilita la activación y la desactivación de algunos (por clase o categoría, además de por nivel). TraceSources tiene un inconveniente, en comparación con log4net y NLog, en que cada TraceSource que cree en su código debe configurarse explícitamente en app.config (si desea que se registre realmente).

log4net y NLog tienen un concepto jerárquico en el que si el registrador exacto que solicitó no está configurado explícitamente, se verifica su "ascendencia" para ver si hay "ancestros" configurados y, de ser así, el registrador solicitado "hereda" esas configuraciones. Los antepasados son simplemente las partes del nombre del registrador delimitadas por ".". (Por lo tanto, si solicita un registrador llamado "ABC.DEF.GHI" , los ancestros serían "ABC.DEF" y "ABC" ). También es posible (¿necesario?) Tener una configuración de registrador "raíz" en el archivo app.config en el que TODAS las solicitudes del registrador retrocederán si no están configuradas explícitamente y no hay ancestros configurados. Por lo tanto, podría configurar solo un registrador "raíz" para que se registre a un cierto nivel y todos sus registradores en su código se registrarán en ese nivel. Alternativamente, puede configurar el registrador "raíz" para que esté "apagado" y luego activar uno o más registradores explícitamente (o configurando un antepasado). De esta manera, NO los registradores se registrarán EXCEPTO para aquellos que están configurados.

Si mira here , encontrará un interesante envoltorio alrededor de System.Diagnostics TraceSources que proporciona una capacidad de herencia muy similar a log4net y NLog.

Para ilustrar:

Un patrón de uso común para los registradores en log4net y NLog es obtener un registrador como este:

//log4net static ILog logger = LogManager.GetLogger( System.Reflection.MethodBase.GetCurrentMethod().DeclaringType); //NLog static Logger logger = LogManager.GetCurrentClassLogger();

En ambos casos, el nombre del registrador será el nombre de tipo totalmente calificado.

En el archivo app.config, puede, si lo desea, configurar solo el registrador "raíz" y ambos registradores heredarán la configuración del registrador raíz (nivel, agregadores / objetivos, etc.). Alternativamente, puede configurar un registrador para algún espacio de nombres. Cualquier registrador cuyo tipo esté definido en ese espacio de nombres heredará la configuración del registrador.

Basta de log4net y NLog, probablemente ya sepa cómo funcionan.

El enlace anterior ilustra un contenedor basado en TraceSource que permite una configuración similar. Entonces, si quisieras, podrías hacer algo como esto en tus clases:

static TraceSource ts = new TraceSource( System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

Con el envoltorio vinculado anteriormente, puede configurar un TraceSource a un nivel superior (clase / espacio de nombres jerárquico, no a nivel) y heredar esas configuraciones en registradores de nivel inferior.

Entonces, si su nombre de tipo completo es algo como esto: ABC.DEF.GHI, entonces puede configurar un TraceSource para ABC o ABC.DEF (nivel de espacio de nombres) y la clase "GHI" heredaría la configuración. Esto realmente podría reducir la cantidad de configuración que tiene que hacer.

Tenga en cuenta que no está limitado (con ninguna de estas plataformas de registro) a usar el tipo o el nombre de la clase para obtener el registrador. Puede definir su propio esquema de nombres de registrador, posiblemente basado en áreas funcionales ("Comunicación", "Comunicación.Enviar", "Comunicación.Recibir", etc.). Una vez más, puede solicitar un logger / TraceSource en el grado más alto de granualaridad (o no) y luego configurarlo en cualquier nivel de granularidad que tenga sentido.

Por lo tanto, puede solicitar registradores en su código de esta manera:

ILog logger = LogManager.GetLogger("Communication.Receive"); ILog logger = LogManager.GetLogger("Communication.Send"); Logger logger = LogManager.GetLogger("Communication.Receive"); Logger logger = LogManager.GetLogger("Communication.Send"); TraceSource ts = new TraceSource("Communication.Receive"); TraceSource ts = new TraceSource("Communication.Send");

Si configura solo "Comunicación" en su archivo app.config, entonces todos los registradores heredarán esas configuraciones (ya que son descendientes de "Comunicación"). Si configura solo "Commuincation.Receive", solo se registrarán los registradores "Communication.Receive". Los registradores "Communication.Send" serán deshabilitados. Si configura tanto "Comunicación" como "Comunicación.Recibir", los registradores "Comunicación.Recibida" se registrarán en la configuración "Comunicación.Recibida" mientras que los registradores "Comunicación.El remitente" se registrarán en la configuración "Comunicación". En log4net y NLog, la herencia puede ser más que eso, pero no sé lo suficiente para hacerlo.

Una cosa que extraña al usar System.Diagnostics es la flexibilidad para formatear su formato de salida de registro muy fácilmente. Hay una biblioteca de terceros que proporciona un formato configurable muy bueno para el registro basado en TraceSource. Puedes encontrarlo here .

He utilizado Common.Logging algunos. Principalmente en prototipos, pero podría usarlo en nuestro próximo proyecto. Funciona bastante bien y es relativamente fácil escribir su propia abstracción de registro para conectarlo (por ejemplo, si desea escribir una abstracción de TraceSource similar a la que he vinculado anteriormente). Dos cosas importantes que faltan en Common.Logging en este momento (aunque su sitio web dice que están programadas para la próxima versión) son los contextos de registro (como log4net y NLog NDC / MDC / GDC objetos y System.Diagnostics.CorrelationManger.LogicalOperationStack ) y compatibilidad con Silverlight. Aún puedes interactuar con los objetos de contexto log4net o NLog en tu código mientras usas Common.Logging, pero ese tipo de derrotas no es el propósito.

¡No sé si ayudé o no!

Aquí hay algunos puntos principales que haría sobre log4net, NLog y TraceSource:

log4net: muy popular, probablemente necesitando algunas actualizaciones, al menos construido en .NET 4.0, última versión hace unos años, muy flexible.

NLog: muy similar a log4net en muchos aspectos, nueva versión ahora (acaba de salir la versión beta de NLog 2.0)

TraceSource: sin dependencia de terceros, sin un esfuerzo por su parte (o el de alguien) no tan poderoso como log4net o NLog (deficiencias clave, jerarquía del registrador, formato de salida, ambos fácilmente accesibles a través de los enlaces anteriores), Microsoft instruye en muchos de sus componentes con System.Diagnostics para que pueda obtener la salida de registro de Microsoft y su salida de registro intercalada. (En general, es bastante fácil capturar los diagnósticos del sistema en otros sistemas de registro, por lo que podría no ser un gran problema).

Aunque no he usado mucho log4net ni NLog, entre los dos me inclino por NLog, principalmente debido a la nueva versión que acaba de salir (beta). Creo que TraceSource también es una opción razonable, aunque más rudimentaria, especialmente si implementa la jerarquía del registrador y usa la biblioteca de Ukadc.Diagnostics vinculada anteriormente.

O bien, use Common.Logging y puede evitar o retrasar la decisión de su plataforma de registro subyacente hasta que esté listo. Un aspecto muy útil de Common.Logging, para mí de todos modos, es que puede "probar" las plataformas de registro a medida que desarrolla su producto sin tener que cambiar el código de su aplicación. No tiene que esperar hasta que haya decidido una plataforma de registro específica para agregar el registro a su código. Agrégalo ahora a través de la API de Common.Logging. Cuando se acerque a la entrega, debería haber reducido su elección de plataforma de registro. Entregue con esa plataforma (si redistribuye la plataforma de registro) y listo. Todavía puedes cambiar más adelante si quieres.

Sé que esto es antiguo, pero System.Diagnostics.Trace es bastante fácil de configurar si lo mantienes simple. He estado usando el simple bloque de configuración de escritor de texto durante años, copiado directamente de los documentos de MSDN.

Nadie lo menciona muy a menudo, pero en su código, puede usar la información de seguimiento Trace.Trace, Trace.TraceWarning y Trace.Trace incorporada para separar fácilmente 3 niveles de salida de seguimiento y luego en el archivo de configuración elegir el nivel de salida (ver config abajo). Si elige Información en el "EventTypeFilter" de la configuración, obtendrá los 3 en su salida. Si elige Error, solo obtendrá mensajes de TraceError en su salida. La mayoría de las veces, solo dejo el mío en Error, por lo que si algo sucede en mi aplicación, ya tendré esa salida en mi archivo de rastreo. Dentro de mis bloques de captura, agregaré código TraceError para generar información útil. TraceInformation es bueno para generar cosas como la sincronización o los puntos en el código por el que has pasado, y arrojar valores variables en el camino. TraceWarning es bueno para cosas que son manejables, pero no deseables, como es posible que un servicio web esté tardando mucho tiempo en completarse o que la cantidad de registros de datos devueltos supere un umbral que pueda causar problemas en el futuro.

Hay un pequeño inconveniente, ya que todas estas líneas de código de rastreo aún se ejecutan independientemente del nivel de compilación. Si están configurados para no producir, eso debería reducir la sobrecarga un poco. Pero si está escribiendo código de alto rendimiento, es posible que desee ajustar esas líneas en marcadores de compilación condicional.

<system.diagnostics> <sharedListeners> <add name="MyTraceListener" traceOutputOptions="DateTime" type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="MyApplicationName_Trace.log">  <filter type="System.Diagnostics.EventTypeFilter" initializeData="Error" /> </add> </sharedListeners> <trace autoflush="true" indentsize="4"> <listeners> <add name="MyTraceListener" /> </listeners> </trace> </system.diagnostics>