1. Inicio
  2. Pregunta y respuesta
  3. C# Logging. ¿Qué debería usar?

C# Logging. ¿Qué debería usar?

2011-01-12 36 views
27

Estoy considerando cambiar a una nueva solución de registro unificada para usar en nuestra nueva línea de productos y quería ver lo que pensaban algunas personas en Stack Overflow. Necesitaremos el registro para una variedad de aplicaciones: ASP .net, servicios de Windows, servicios web, aplicaciones wpf, etc. Somos una tienda de Windows solamente.C# Logging. ¿Qué debería usar?

Algunos de nuestros requisitos para una solución de registro incluyen:

1) Registro de gestión de archivos

- Ability to split files up over a certain size 
- Ability to auto archive/delete after certain period of time

2) Capacidad para enviar mensajes de correo electrónico en ciertos tipos de mensajes registrados (errores, por ejemplo)

3) Posibilidad de escribir mensajes en el registro de eventos de Windows

- We need to be able to specify where it's being written in the event log. 
    It would also be nice if it would automatically create the event log source if it does exist.

Empecé a buscar en nLog, Windows trace y log4net. No estoy limitado a estos 3, solo son pocos los que surgieron mucho al buscar.

Fuente

2011-01-12 Cole W

+1

log4net es de lejos el más utilizado y es compatible con todos estos requisitos. Es el que usaría, pero YMMV. – Thorarin

+5

Pruebe esto: http://stackoverflow.com/search?q=[.net]+logging Encontrará muchas respuestas interesantes. –

+0

Duplicado, pero Cole W plantea algunos requisitos específicos que él pensó, lo cual es bueno acerca de esta pregunta. – Marijn

Respuesta

17

log4net es siempre una buena opción.

http://logging.apache.org/log4net/

Fuente

2011-01-12 16:07:41 RQDQ

+3

No, no es una buena opción si desea algo fácil de implementar. Claro, si ya eres usuario de log4net, puede ser fácil para ti. Para cualquiera que nunca lo haya usado antes, configurarlo es un dolor en el culo. – Pedro

+1

¡Menos dolor en el trasero que escribir su propio marco de trabajo maderero! – RichardOD

+1

@Pedro ¿qué estás * implementando *? Puede encontrar ejemplos de app.config para configurar el registrador. –

3

Puede echar un vistazo a Enterprise Library, que tienen un bloque de aplicación para el registro, que es extensible

http://entlib.codeplex.com/

http://entlib.codeplex.com/releases/view/46741

se puede descargar el pdf guía dev, tienen una sección sobre registro (Capítulo 4)

Fuente

2011-01-12 16:06:40 pdiddy

+0

+1 Recibía el enlace :) –

+1

tuvimos * muy * malas experiencias con eso: en servidores web, registró y bloqueó el archivo (es decir, no lo lanzó a tiempo para otro registro), por lo que el siguiente registro fue a otro archivo que tenía GUID como nombre ... muy poco práctico para cualquier entorno de producción ... – veljkoz

+1

Parece que estaba intentando iniciar sesión en el mismo archivo desde múltiples procesos (o usando múltiples 'TraceListeners' ese punto al mismo archivo). Ver: http://stackoverflow.com/questions/1728571/logging-from-multiple-processes-to-same-file-using-enterprise-library-4-1. He estado utilizando Enterprise Library en entornos de producción empresarial desde que se lanzó y he tenido muy buenas experiencias. –

9

Y sólo otro: NLog.

  • Archivos - archivo único o múltiple, con denominación automática de archivos y archivo
  • registro de eventos - la base de datos local o remota - tienda de sus registros en las bases de datos soportadas
  • por .NET red - a través de TCP , UDP, SOAP, protocolos de MSMQ
  • de línea de comandos de la consola - incluyendo código de colores de mensajes
  • de correo electrónico - se puede recibir mensajes de correo electrónico cada vez que errores de aplicación ocurren
  • seguimiento ASP.NET
  • y muchos más

Fuente

2011-01-12 16:10:33

+0

Utilicé NLog en mi proyecto anterior, y me pareció realmente más fácil de configurar que Log4Net (lo que no funcionaría, inexplicablemente). – Shimrod

11

Uso .NET common logging. Puede elegir luego un proveedor específico (NLog, CLog, log4net ...) o incluso crear configuraciones personalizadas.

Fuente

2011-01-12 16:11:19 HuBeZa

+4

Pero, ¿qué sucede si quiero evitar una dependencia en el registro común de .NET? Honestamente, esto parece una capa innecesaria de abstracción para mí. log4net y otros son abstracciones sobre el registro: ¿qué posible razón podría tener para querer intercambiar uno por otro que no sea también un argumento en contra del uso del registro común de .NET? –

+7

Esto es similar al registro de Apache commons para Java, y el mismo argumento se aplica a su existencia. Digamos que está escribiendo bibliotecas que se usarán en otro código. No desea dictar qué marco de registro se usa en ningún código que interactúe con su biblioteca, porque eso significa que el cliente debe tener config para su marco particular. Digamos que si decides usar log4net, otra biblioteca usa NLog, entonces el cliente debe tener ambas configuraciones presentes para usar ambas bibliotecas. Commons le permite heredar el marco de trabajo de registro del código del cliente. – Ceilingfish

0

Puede crear su propia libreta de registro ... Lo hice.

Eche un vistazo a PostSharp http://www.sharpcrafters.com/ tienen muy buenos ejemplos de algunos sistemas de registro básicos.

Fuente

2011-01-12 16:32:48

1

Ver esta pregunta para otra respuesta completa: When should I use Tracing vs Logger.NET, Enterprise Library, log4net or Ukadc.Diagnostics?

En resumen, los principales marcos de registro disponibles son la aplicación del bloque integrado .NET Framework System.Diagnostics, log4net, Nlog y Enterprise Library Logging.

Una comparación de estos marcos principales está disponible en: https://essentialdiagnostics.codeplex.com/wikipage?title=Comparison

1) Registro de gestión de archivos

Todos los principales marcos que figuran por encima del soporte archivos rodar pero creo que salen de la limpieza para usted .

p. Ej. en el pasado he usado un trabajo programado de Windows que usa robocopy con "/ mov/minage X" para mover archivos viejos a otro lugar, luego eliminarlos o lo que sea.

El EventSchemaTraceListener utilizado en System.Diagnostics, que I blogged about recently, tiene una opción LimitedCircularFiles, pero no hay mucho soporte de herramientas para ver los registros (están en XML).

2) Capacidad para enviar mensajes de correo electrónico en ciertos tipos de mensajes registrados (errores, por ejemplo)

Todos los principales marcos mencionados anteriormente apoyo esta ya sea directamente o a través de extensiones (oyentes adicionales).

3) Capacidad para escribir mensajes al evento ventanas ingrese

Una vez más, todos los marcos principales apoyar esto, sin embargo, en general, recomendaría que escribir en el registro de eventos de Windows debe hacerse directamente no a través de rastreo.

Uno de los problemas es sobre qué preguntas para la creación automática de fuentes.

Cualquier escrito al registro de eventos (que pasa por EventLog.WriteEvent) se intente automáticamente para crear la fuente en el primer mensaje de registro si no existe - el problema es con seguridad, sólo los administradores se les permite para crear fuentes, por lo que se ejecuta como un usuario normal esto falla.

Debido a esto, realmente necesita agregar un EventLogInstaller, para que la fuente se cree en el momento de la instalación (la instalación la realiza el administrador). Una vez creado, cualquier proceso puede escribir en la fuente.

Esto me lleva a recomendar que necesite crear y escribir en el código de registro de eventos para garantizar que el origen del registro de eventos sea el mismo. Además, si escribe en el registro de eventos en general, no desea poder 'apagarlo' mediante una configuración incorrecta.

Mi recomendación personal es para el .NET Framework System.Diagnostics, en particular, el Service Trace Viewer es excelente para diagnosticar problemas, en particular en entornos de varios niveles y múltiples hilos si se usa WCF donde puede pasar la correlación se identifica a través de los niveles.

Fuente

2013-04-21 08:09:36

Cuestiones relacionadas

 Cuestiones relacionadas