write - C#Logging. ¿Qué debería usar?
log error c# (7)
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.
Algunos de nuestros requisitos para una solución de registro incluyen:
1) Gestión de archivos de registro
- Ability to split files up over a certain size
- Ability to auto archive/delete after certain period of time
2) Posibilidad de enviar correos electrónicos sobre 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 nLog, Windows trace y log4net. No estoy limitado a estos 3, solo son pocos los que surgieron mucho al buscar.
Puede crear su propia libración de registro ... Lo hice.
Eche un vistazo a PostSharp http://www.sharpcrafters.com/ que tienen muy buenos ejemplos de algunos sistemas básicos de registro.
Puede echarle un vistazo a Enterprise Library, tienen un bloque de aplicaciones para el registro que es extensible
http://entlib.codeplex.com/releases/view/46741
puedes descargar la guía de desarrollo pdf, tienen una sección sobre registro (Capítulo 4)
Use el registro común de .NET . Puede elegir luego un proveedor específico (NLog, CLog, log4net ...) o incluso crear configuraciones personalizadas.
Y solo otro: NLog .
- Archivos: archivo único o múltiple, con asignación y archivo automático de archivos
- Registro de eventos - Base de datos local o remota - almacene sus registros en bases de datos compatibles
- por .NET Network - usando protocolos TCP, UDP, SOAP, MSMQ
- Consola de línea de comandos, incluida la codificación por colores de los mensajes
- Correo electrónico: puede recibir correos electrónicos cada vez que se producen errores de aplicación
- Rastro de ASP.NET
- y muchos más
log4net es siempre una buena opción.
http://alexworx.github.io/ALox-Logging-Library/
es una biblioteca sencilla que es genial si tienes altas exigencias de rendimiento.
Consulte esta pregunta para obtener otra respuesta integral: ¿ Cuándo debo usar Tracing vs Logger.NET, Enterprise Library, log4net o Ukadc.Diagnostics?
En resumen, los principales marcos de registro disponibles son el .NET Framework System.Diagnostics integrado, log4net, NLog y Enterprise Library Logging Application Block.
Una comparación de estos marcos principales está disponible en: https://essentialdiagnostics.codeplex.com/wikipage?title=Comparison
1) Gestión de archivos de registro
Todos los marcos principales enumerados anteriormente admiten archivos continuos, pero creo que te dejan la limpieza.
por ejemplo, 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, del que publiqué recientemente en mi blog , tiene una opción de LimitedCircularFiles, pero no hay mucho soporte de herramientas para ver los registros (están en XML).
2) Posibilidad de enviar correos electrónicos sobre ciertos tipos de mensajes registrados (errores, por ejemplo)
Todos los marcos principales enumerados anteriormente admiten esto directamente o mediante extensiones (oyentes adicionales).
3) Posibilidad de escribir mensajes en el registro de eventos de Windows
Una vez más, todos los marcos principales lo soportan, sin embargo, generalmente recomendaría que escribir en el registro de eventos de Windows se haga directamente y no a través del rastreo.
Uno de los problemas es sobre qué preguntaste para la creación automática de fuentes.
Cualquier escritura en el registro de eventos (que pasa por EventLog.WriteEvent) intentará crear automáticamente la fuente en el primer mensaje de registro si no existe: el problema es con la seguridad, solo los administradores pueden crear fuentes, por lo que se ejecuta como 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 asegurarse de 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 .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 subprocesos si se usa WCF, donde puede pasar la correlación identificada entre niveles. .