logging - configurar - log4net table

Log4net/Logging-¿Qué has encontrado útil? (8)

Descubrí que obtengo datos valiosos al configurar proyectos para usar Log4PostSharp al inicio del desarrollo. Básicamente, combinado con el motor PostSharp , puede colocar un atributo en los métodos y registrará todas las llamadas con el parámetro y los valores de retorno. Lo configuré a nivel de depuración en el archivo Assembly.cs para que, por defecto, se registren todas las llamadas de métodos que no sean captadores o definidores de propiedades.

Si se deja sin control, puede producir una gran cantidad de datos (me aseguro de no registrar nada más a nivel de depuración para que sea fácil de encender y apagar y eliminarlo por completo de las versiones de la versión si el rendimiento es un problema), pero con un buen visor de registros (uso BareTail ) puede identificar errores complicados muy rápidamente. Es especialmente bueno para determinar el método en el que se encontraban tus diferentes hilos en el momento en que surgió un problema.

Utilizo un appender de archivo rodante para que los datos más recientes estén siempre disponibles sin que los archivos alcancen tamaños ridículos.

Acabo de empezar a usar Log4Net y buscaba ver lo que ha encontrado útil en sus experiencias de registro.

¿Qué tipo de cosas has encontrado útiles para iniciar sesión? lo que terminó siendo solo ruido; ¿Cuándo utiliza los diferentes niveles de registro (DEBUG, INFO, etc.)? ¿Tiene un formato estándar para cada entrada de registro? ¿Hay cosas que SIEMPRE registras?

Cualquier trampa? ¿Buenos artículos sobre la tala en general?

Actualización: ¿Dónde te registras? ¿Qué anexos y por qué?

¡Gracias!

Estoy basando mi respuesta en la excelente respuesta de Robert Kozak, aunque no uso mi registro de la misma manera

Yo uso cinco tipos de declaraciones de registro:

DEPURAR
INFO
ADVERTENCIA
ERROR
FATAL

Las declaraciones DEBUG son declaraciones que son útiles cuando aún está escribiendo una aplicación y cuando necesita una comprensión completa de qué / dónde está su flujo de ejecución. Puede usar las declaraciones DEBUG para medir la cola frente a un bloqueo, o verificar los nombres de usuario de los usuarios que inician sesión, o incluso los parámetros para una determinada llamada de SQL que ha sido preocupante. DEBUG es para declaraciones que generalmente no son necesarias para ser conocidas.

INFO debe usarse siempre que haya información que será muy útil si algo sale mal, pero no indica que algo haya salido mal. Si usa demasiadas declaraciones INFO, sus registros se hincharán y no serán útiles, así que tenga cuidado. Use INFO para cualquier información crítica que necesitará en caso de error, y no es en ningún lugar cerca de dónde se lanzará el error.

Use el nivel WARN si ha detectado un valor recuperable, pero aún inesperado (al menos un poco esperado, porque lo detectó). Indica que su aplicación PUEDE estar en un estado no funcional, pero que cree que puede recuperar / continuar en la ruta de ejecución actual.

Las advertencias de ERROR son para cuando detectas una excepción inesperada. Si está recuperando / volviendo a intentar el método actual, sugeriría usar WARN. Si está cancelando / rescatando, use el ERROR. Incluso si su programa puede continuar, ERROR significa que estaba intentando hacer algo y fue rechazado, por lo que se está moviendo hacia otras cosas.

FATAL es para usar cuando atrapas algo a un nivel muy por debajo del lugar donde fue lanzado, y esencialmente no tienes idea de lo que está pasando. Esto significa que ni siquiera está intentando continuar con la ejecución, simplemente va a registrar cada bit de información posible a su disposición y luego tratar de salir correctamente. Los errores FATAL se utilizan con poca frecuencia porque, en general, si detecta un error, tiene suficiente información para intentar continuar con la ejecución. Pero en los escenarios en los que podría producirse una corrupción si lo intenta y continúa, registre un error FATAL y luego huya.

En cuanto a dónde se está conectando. Por lo general, me gusta iniciar sesión en una carpeta ''compartida'' en mis servidores de aplicaciones (tenga cuidado con los permisos para que no sean públicos), de modo que los registros sean de fácil acceso y siempre sean mi primer paso para la depuración. Si es posible, configúrelo para que los errores que sean ADVERTENCIA, ERROR o FATAL se envíen por correo electrónico para que tenga una advertencia "avanzada".

Aclamaciones

Hay otro visor de log log4net (aparte de la motosierra Apache) que mi compañía ha estado usando durante algún tiempo, se llama "log4net Dashboard" y está siendo desarrollado por una compañía noruega (creo) llamada FaktNet, su sitio web es http: // www.l4ndash.com .

Proporciona un panel de control basado en la web que es bastante intuitivo y proporciona una buena visión general del registro, se puede usar con muchos agregadores diferentes (como el archivo rodante o el servidor SQL), pero no es gratis como lo es la motosierra Apache. Sin embargo, sí tienen una licencia de desarrollador, que es gratuita y solo permite el uso local, lo que sería suficiente, por ejemplo, para un profesional independiente que desee supervisar sus sitios (un único panel de control l4n puede conectarse a múltiples fuentes de registro).

FaktNet tiene varias licencias, dependiendo de cuántos usuarios se supone que deben poder acceder al panel de control, y su licencia Enterprise no es realmente costosa (creo que es de $ 600). Dada su capacidad para acceder a múltiples registros, puede ser un activo importante para un equipo de desarrollo que está desarrollando y monitoreando muchos sitios web de mediana a gran escala.

Log4Net con motosierra apache . La motosierra es un panel para ver tus mensajes de registro en tiempo real. Puede manejar múltiples aplicaciones, realizar filtrado sobre la marcha y algunas otras funciones útiles.

En caso de duda, inicie sesión (preferiblemente en un nivel superior como DEBUG o INFO o cree su propio nivel). Puede configurar lo que obtiene salida en el archivo de configuración.

Otro apender realmente útil es el DBAppender que puede registrar información en una base de datos, lo que obviamente es increíblemente útil para consultar un registro.

Más información sobre esto en este artículo .

También hay otro marco de registro para ASP.NET llamado ELMAH . Aunque no es un verdadero marco de registro, sino más bien un marco de excepción.

Las características interesantes incluyen:

0 código / recompilación para implementarlo
tiene una interfaz de usuario web para ver los errores
RSS para errores
Se puede configurar para volcar errores a SQL.

Yo uso cuatro tipos de declaraciones de registro:

DEPURAR
INFO
ADVERTENCIA
ERROR

Utilizo DEBUG para las declaraciones que quiero verificar durante una sesión de depuración. Por lo general, estos no duran para la versión de lanzamiento. Aquí es donde estoy comprobando el valor de una variable o iniciando sesión en un método.

Uso INFO para cadenas de conexión, configuración y partes generales de información que siempre quiero ver en un registro.

ADVERTENCIA se usa raramente para cosas de las que no estoy seguro o posibles condiciones de error o incluso para verificar una excepción que sé que se manejará en la pila.

Normalmente solo uso ERROR en un Bloqueo de captura para informar sobre una excepción y en un Administrador de excepciones al que se llama cuando ningún otro método maneja la excepción.

Todas las excepciones se registran en el nivel de ERROR en el nivel más alto posible en la pila de llamadas (normalmente en los controladores de eventos, etc.)
La entrada del usuario que causa un problema se registra en el nivel WARN (porque puede indicar que necesitamos mejorar nuestra interfaz de usuario para guiar mejor al usuario)
Las actividades "significativas" se registran a nivel de INFO (es decir, cualquier cosa que implique facturar a la tarjeta de crédito de un cliente, las consultas a un API de un tercero, etc.), incluidos los datos involucrados (generalmente, serializados en XML, con cualquier información confidencial eliminada)
Se pueden registrar actividades muy detalladas a nivel DEBUG

Rara vez utilizamos el registro de nivel FATAL .

Normalmente implementamos con un RollingLogFileAppender en el nivel INFO y un SmtpAppender en el nivel ERROR .