Marco de registro, una buena idea?

Question

En primer lugar, disculpas por el título que suena subjetivo. Esto es una pregunta directa.

Actualmente estoy trabajando en un conjunto de herramientas:

• Un servicio de Windows C #, principalmente mantener una base de datos Oracle.
• Un servicio de Windows C #, (que será utilizado en sitios de múltiples nodos) para procesar el contenido de la base de datos.
• Una interfaz web ASP.NET para Facilitar la gestión del conjunto. " sistema "

Actualmente, los servicios de Windows se han desarrollado como aplicaciones de consola (para facilitar la depuración / desarrollo) y estoy en medio de convertirlos a servicios. Después de probar durante un par de días con estos servicios, descubro que me gustaría aumentar la granularidad de mi registro. Me estoy dando cuenta de que echo de menos Console.WriteLine () y me gustaría proporcionar una fuente de registro alternativa como un archivo plano para este tipo de salida. Esto me ha llevado a pensar, "¿Debo estar usando un marco o tengo suficiente?",

La razón por la que mencioné los aspectos que estoy desarrollando es para proporcionar una perspectiva de mi situación. Un "núcleo" Se ha creado DLL, común en todos los componentes, abstrayendo la capa de interacción entre las aplicaciones y la base de datos. Es dentro de esta DLL que se ha creado una clase que intentará " registrar en una tabla en la base de datos " de lo contrario, en caso de error " iniciar sesión en el registro de eventos local " ;. Esto es, es el alcance del registro.

A lo largo de las herramientas mencionadas anteriormente, hay varias instancias de registro que no son diferentes a:

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

Aunque es bastante básico, este método hace uso de la reflexión para identificar la fuente del error.

Mi pregunta

En cuanto a mi solución de registro actual, aparece " suficiente " en cuanto a lo que hace y cómo se integra con todas mis soluciones. Sin embargo, he estado buscando en los marcos de registro (notablemente log4net) y sus características me impresionan. ¡La capacidad de, si es necesario en el futuro, agregar otro formato de salida (como un servidor SMTP) me suena genial! :)

¿Qué me gustaría saber son los beneficios de pasar a un marco (como log4net)? ¿Hasta qué punto tendré que adaptar mi código? ¿Estoy o no solo mirando el pasto más verde del otro lado? Y finalmente, pero probablemente lo más importante, ¿estoy haciendo lo correcto? ¿Debo agregar la capacidad a mi clase de registro a " LogDebug " y acabar con eso? Lo último que querría hacer es renovar completamente mi suite, solo para un " básico " característica, pero si hay otros beneficios (diseño, confianza, buenas prácticas, etc.), me interesa.

Gracias,

Answer 1

El registro adecuado es especialmente beneficioso cuando se ejecuta código en varios sistemas remotos, por lo que recuerdo, log4net le permitirá enviar sus registros a un servidor de syslog remoto sin mucha sobrecarga de codificación (lo que significa que puede ver sus registros desde todas las máquinas en una sola) lugar centralizado) hacer esto reducirá enormemente el tiempo que le lleva obtener información relacionada con un error o problema con el sistema, y ??también le dará una indicación de la prevalencia del problema.

Como se mencionó en otras publicaciones, log4net también permite múltiples agregadores y múltiples niveles de registro, por lo que determinar dónde desea cierta información de registro (es decir, en una base de datos o en un archivo plano local, incluso log4net le permite escupir los registros a través de telnet). ) para ser almacenado es un doddle absoluto.

En cuanto a su implementación, hay varios buenos sitios que lo hablan a través de la configuración. La forma en que realmente hace uso de los objetos de registro que log4net le brinda es una opción arquitectónica, pero simplemente puede cambiar el constructor de un objeto para que tome un objeto log4net y desde este objeto, simplemente use el objeto log4net como lo haría con Console.WriteLine .

Encuentro la serie de tutoriales aquí son particularmente útiles, y también irán a más profundidad que yo aquí sobre los beneficios y las diferentes formas de configurar log4net.

Answer 2

Sí. Es una buena idea utilizar un marco de registro existente y probado (como Log4net).

Log4Net se puede configurar en tiempo de ejecución (ideal para rastrear problemas en el código de producción).

Como señaló un comentarista, también es muy fácil de usar.

Answer 3

Sí, definitivamente desea utilizar un marco de registro. Un marco de registro le permitirá:

  
• Establezca los niveles de registro para las diferentes instancias del registrador.
  
• Establecer " appenders " o salida para cada una de las diferentes instancias de logger.

Quizás, lo que es más importante, si utiliza un marco de registro, es muy fácil cambiar una implementación del marco de registro por otra (quizás una implementación nula que simplemente descarta los mensajes); mientras que, si escribe todas sus declaraciones de registro, directamente, cambiar la implementación será una pesadilla.

Answer 4

Creo que deberías usar Log4net, simplemente porque siempre es mejor reutilizar que construir tu propio objeto. Log4net ha sido utilizado por muchos desarrolladores y está bastante maduro.

Piense en su perspectiva de mantenimiento; en el transcurso de uno o dos meses, es posible que tenga que ajustar un poco su clase de registro personalizado, para agregar algo de soporte de subprocesos múltiples, etc. Y cuando esté arreglando los errores que surgieron de su clase de registro, se perderá Log4net.

Answer 5

Bueno, uno de los mayores beneficios es no tener que mantener el código usted mismo. La mayoría de las veces, los marcos de registro tienen mucha más funcionalidad que su propia solución. Debido a que están tan enfocados en el registro, esos marcos generalmente son bastante completos en cuanto a la funcionalidad y las formas de implementarlo. Y luego está la fiabilidad; no hay nada peor que un marco de registro que no está registrando nada porque tiene errores. ;)

Tome, por ejemplo, ELMAH para las aplicaciones ASP.net. También incluye notificaciones, exportaciones a varios formatos de destino, etc. Cosas que son bastante útiles pero que nunca construirás tú mismo a menos que realmente lo necesites.

La cantidad de cambios que se necesitan en su código, obviamente, depende tanto de su código como del marco de su elección. Es difícil decir algo sobre eso.

Answer 6

Le voy a dar una nota a NLog ( http://nlog-project.org/home ) ya que no sufre el síndrome 'Puerto de Java Recto - luego reescritura' de la mayoría de las librerías de .ss.

Algunos de los beneficios clave para nosotros fueron el muy rápido Logger.IsFooEnabled (lectura volátil) y el rendimiento general del sistema.

Sin embargo, para cada uno es propio, pero personalmente prefiero NLog para mis proyectos (y algunos de mis clientes también).

Saludos, Florian

Answer 7

La ventaja de usar un buen marco de registro como Log4Net es que tienen un pequeño impacto en su código en términos de líneas de código que debe modificar (en otras palabras, solo tiene que modificar cada línea de registro existente).

Además, si le preocupa alterar su código si cambia los marcos, o si cree que desea rodar el suyo, siempre puede crear su propia interfaz para un marco de registro. Entonces, solo tendrá que cambiar su código en un lugar después de eso.

Answer 8

Creo que los administradores de sistemas esperan que los servicios se registren en el registro de eventos de la aplicación en Windows.

Busque System.Diagnostics.EventLog, aunque log4net también escribirá en eso ...

Answer 9

La declaración inicial en el sitio web log4j puede ayudar en algunos de sus Preguntas, los principios subyacentes son los mismos de log4net:

  

Con log4j es posible habilitar   registro en tiempo de ejecución sin modificar   La aplicación binaria. El log4j   paquete está diseñado para que estos   Las declaraciones pueden permanecer en el código enviado.   sin incurrir en un alto rendimiento   costo. El comportamiento de registro puede ser   controlado mediante la edición de una configuración   Archivo, sin tocar la aplicación.   binario.

     

Usando una jerarquía de logger es   posible controlar qué registro   las declaraciones son de salida en forma arbitraria   Granularidad fina pero también gran facilidad.   Esto ayuda a reducir el volumen de datos registrados.   salida y minimizar el costo de   registro.

En este caso, claramente no hay necesidad de reinventar la rueda. La mayoría de los marcos de registro son un tanto sencillos, por lo que la extensión de los cambios probablemente dependerá del tamaño de sus programas existentes.

Answer 10

si escribe su clase de registrador correctamente, será fácilmente prescindible para cualquiera de sus necesidades. Cualquier marco puede impresionarlo con muchas características, pero otro marco es otra variable en su proceso de depuración, ya que le puede dar un error que no existe o puede cometer un error por sí mismo en combinación con su aplicación. Si está listo para realizar pruebas beta para proyectos de software de código abierto, está bien ...

En su lugar, escribiría una clase de registro con la capacidad de ampliar las características que le parezcan interesantes para su proyecto en función de la lista de características que tienen los marcos conocidos. No veo ningún problema para registrar algo en el archivo y luego enviarlo por smpt, solo una pequeña función hace el trabajo.

Además, puede escribir su propia clase que será bastante abstracta y poner su código básico allí, si alguna vez necesita usar un marco externo para probar su clase, podría usarlo con un impacto mínimo en el código. Eche un vistazo a cómo se implementan los marcos en el nivel de código.

piense que tendrá que aprender a usar estos marcos de manera adecuada cuando solo necesite por ahora registrar una parte muy pequeña ...