.net - page - Mejores prácticas de registro

nlog net core

Question

Me gustaría obtener historias sobre cómo las personas manejan el rastreo y el registro en aplicaciones reales. Aquí hay algunas preguntas que pueden ayudar a explicar su respuesta.

Marcos

¿Qué marcos usas?

• log4net
• System.Diagnostics.Trace
• System.Diagnostics.TraceSource
• Bloque de aplicación de registro
• ¿Otro?

Si utiliza el rastreo, ¿hace uso de Trace.Correlation.StartLogicalOperation?

¿Escribes este código manualmente, o utilizas algún tipo de programación orientada a aspectos para hacerlo? ¿Quieres compartir un fragmento de código?

¿Proporciona alguna forma de granularidad sobre las fuentes de rastreo? Por ejemplo, WPF TraceSources le permite configurarlos en varios niveles:

• System.Windows - configuraciones para todos los WPF
• System.Windows.Animation - anulación específicamente para la animación.

Oyentes

¿Qué salidas de registro utilizas?

• Archivos de texto
• Archivos XML
• Registro de eventos
• ¿Otro?

Si usa archivos, ¿utiliza registros rotativos o solo un archivo? ¿Cómo se hacen los registros disponibles para que la gente los consuma?

Visita

¿Qué herramientas utilizas para ver los registros?

• Bloc
• Cola
• Visor de eventos
• Systems Center Operations Manager / Microsoft Operations Manger
• Visor de rastreo de servicio WCF
• ¿Otro?

Si está creando una solución ASP.NET, ¿también utiliza ASP.NET Health Monitoring? ¿Incluyes la salida de seguimiento en los eventos del monitor de estado? ¿Qué pasa con Trace.axd?

¿Qué pasa con los contadores de rendimiento personalizados?

Answer 1

Como autores de la herramienta, nosotros, por supuesto, usamos SmartInspect para registrar y rastrear aplicaciones .NET. Usualmente usamos el protocolo de canalización con nombre para el registro en vivo y los archivos de registro binarios (encriptados) para los registros del usuario final. Utilizamos la Consola SmartInspect como herramienta de visualización y monitoreo.

En realidad, existen bastantes marcos de trabajo y herramientas de registro para .NET. Hay una visión general y comparación de las diferentes herramientas en DotNetLogging.com .

Answer 2

En lo que respecta al registro orientado a aspectos, me recomendaron PostSharp en otra pregunta de SO:

Aspecto orientado al registro con Unity / T4 / cualquier otra cosa

Vale la pena visitar el enlace proporcionado en la respuesta si está evaluando los marcos de registro.

Answer 3

Hay muchas buenas recomendaciones en las respuestas.

Una mejor práctica general es considerar quién leerá el registro. En mi caso será un administrador en el sitio del cliente. Así que registro los mensajes que les dan algo en lo que pueden actuar. Por ejemplo, "No se puede inicializar la aplicación. Esto generalmente es causado por ......"

Answer 4

No a menudo me desarrollo en asp.net, sin embargo, cuando se trata de registradores, creo que muchas de las mejores prácticas son universales. Estos son algunos de mis pensamientos aleatorios sobre el registro que he aprendido a lo largo de los años:

Marcos

• Use un marco de abstracción de registrador, como slf4j (o enrolle el suyo), de modo que desacople la implementación del registrador de su API. He visto una serie de marcos de logger que van y vienen, y es mejor que puedas adoptar uno nuevo sin muchas complicaciones.
• Intente encontrar un marco que admita una variedad de formatos de salida.
• Intente encontrar un marco que admita complementos / filtros personalizados.
• Utilice un marco que se puede configurar con archivos externos, de modo que sus clientes / consumidores puedan modificar la salida del registro fácilmente para que las aplicaciones comerciales de administración de registros puedan leerlo fácilmente.
• Asegúrese de no exagerar en los niveles de registro personalizados, de lo contrario, es posible que no pueda moverse a diferentes marcos de registro.

Salida del registrador

• Intente evitar los registros de estilo XML / RSS para el registro que podrían encontrar fallas catastróficas. Esto es importante porque si el interruptor de alimentación se apaga sin que su registrador escriba la etiqueta de cierre </xxx> , se rompe su registro.
• Hilos de registro. De lo contrario, puede ser muy difícil rastrear el flujo de su programa.
• Si tiene que internacionalizar sus registros, es posible que desee que un desarrollador solo inicie sesión en inglés (o en el idioma que elija).
• A veces, tener la opción de insertar declaraciones de registro en consultas SQL puede ser un salvavidas en situaciones de depuración. Como:

-- Invoking Class: com.foocorp.foopackage.FooClass:9021 SELECT * FROM foo;

• Desea registro de nivel de clase. Normalmente, tampoco se desean instancias estáticas de registradores; no vale la pena la microoptimización.
• Marcar y categorizar las excepciones registradas a veces es útil porque no todas las excepciones son iguales. Por lo tanto, conocer un subconjunto de excepciones importantes es útil para un jefe de tiempo, si tiene un monitor de registro que necesita enviar notificaciones en estados críticos.
• Los filtros de duplicación guardarán tu vista y disco duro. ¿Realmente desea ver la misma declaración de registro repetida 10 ^ 10000000 veces? ¿No sería mejor solo recibir un mensaje como: This is my logging statement - Repeated 100 times

También vea esta pregunta mía .

Answer 5

No estoy calificado para comentar sobre el registro para .Net, ya que mi pan y mantequilla es Java, pero hemos tenido una migración en nuestro registro durante los últimos 8 años, puede encontrar una analogía útil para su pregunta.

Comenzamos con un registrador Singleton que fue usado por cada hilo dentro de la JVM, y establecimos el nivel de registro para todo el proceso. Esto dio como resultado enormes registros si debíamos depurar incluso una parte muy específica del sistema, por lo que la lección número uno es segmentar su registro.

Nuestra encarnación actual del registrador permite múltiples instancias con una definida como la predeterminada. Podemos instanciar cualquier número de registradores secundarios que tengan diferentes niveles de registro, pero la faceta más útil de esta arquitectura es la capacidad de crear registradores para clases y paquetes individuales simplemente cambiando las propiedades del registro. La lección número dos es crear un sistema flexible que permita anular su comportamiento sin cambiar el código.

Estamos utilizando la biblioteca de registros comunes de Apache que se encuentra alrededor de Log4J.

¡Espero que esto ayude!

* Editar *

Después de leer el post de Jeffrey Hantin a continuación, me di cuenta de que debería haber notado en qué se ha convertido nuestro contenedor de registro interno. Ahora es esencialmente una fábrica y se usa estrictamente para obtener un registrador que funcione con el archivo de propiedades correcto (que por razones heredadas no se ha movido a la posición predeterminada). Ya que puede especificar el archivo de configuración de registro en la línea de comandos ahora, sospecho que se volverá aún más simple y si está iniciando una nueva aplicación, definitivamente estoy de acuerdo con su afirmación de que no debería molestarse en envolver el registrador.

Answer 6

Tengo que unirme al coro que recomienda log4net, en mi caso proveniente de un punto de vista de plataforma flexible (escritorio .Net / Compact Framework, 32/64-bit).

Sin embargo, envolverlo en una API de etiqueta privada es un antipatrón importante . log4net.ILogger es la contraparte .Net de la API wrapper de Commons Logging , por lo que el acoplamiento ya está minimizado para usted, y como también es una biblioteca de Apache, eso no suele ser una preocupación porque no está renunciando a ningún control: fork si es necesario

La mayoría de las bibliotecas de envoltorios de casa que he visto también cometen una o más de una letanía de fallas:

42. El uso de un registrador de singleton global (o, de manera equivalente, un punto de entrada estático) que pierde la resolución fina del patrón de registrador por clase recomendado para ninguna otra ganancia de selectividad.
43. No exponer el argumento de Exception opcional , lo que lleva a múltiples problemas:
    • Hace que una política de registro de excepciones sea aún más difícil de mantener, por lo que no se hace nada de manera consistente con las excepciones.
    • Incluso con una política consistente, formatear la excepción en una cadena pierde datos prematuramente. He escrito un decorador personalizado de ILayout que realiza un desglose detallado en una excepción para determinar la cadena de eventos.
44. Si no se exponen las propiedades Is Level Enabled , lo que descarta la posibilidad de omitir el código de formato cuando las áreas o los niveles de registro están desactivados.

Answer 7

Usamos log4net en nuestras aplicaciones web.

La capacidad de personalizar el registro en tiempo de ejecución cambiando el archivo de configuración XML es muy útil cuando una aplicación no funciona correctamente en tiempo de ejecución y necesita ver más información.

También le permite dirigirse a clases o atributos específicos para iniciar sesión. Esto es muy útil cuando tienes una idea de dónde está ocurriendo el error. Un ejemplo clásico es NHibernate donde desea ver solo el SQL que va a la base de datos.

Editar:

Escribimos todos los eventos en una base de datos y el sistema Trace. El registro de eventos que utilizamos para errores o excepciones. Registramos la mayoría de los eventos en una base de datos para que podamos crear informes personalizados y permitir que los usuarios vean el registro si lo desean desde la aplicación.

Answer 8

Utilizamos Log4Net en el trabajo como proveedor de registro, con un contenedor de singleton para la instancia de registro (aunque el singleton está bajo revisión, cuestionando si son una buena idea o no).

Lo elegimos por las siguientes razones:

• Configuración / reconfiguración simple en varios entornos.
• Buena cantidad de appenders pre-construidos.
• Uno de los CMS que usamos ya lo tenía incorporado.
• Buena cantidad de niveles de registro y configuraciones alrededor de ellos.

Debería mencionar, esto está hablando desde un punto de vista de desarrollo de ASP.NET.

Puedo ver algunos méritos en el uso del Rastreo que está en el marco .NET, pero no estoy totalmente vendido, principalmente porque los componentes con los que trabajo no hacen ninguna llamada de Rastreo. Lo único que uso con frecuencia es System.Net.Mail por lo que puedo decir.

Así que tenemos una biblioteca que contiene log4net y dentro de nuestro código solo necesitamos cosas como esta:

Logger.Instance.Warn("Something to warn about");
Logger.Instance.Fatal("Something went bad!", new Exception());
try {
var i = int.Parse("Hello World");
} catch(FormatException, ex) {
Logger.Instance.Error(ex);
}

Dentro de los métodos, hacemos una verificación para ver si el nivel de registro está habilitado, por lo que no tienes llamadas redundantes a la API log4net (por lo tanto, si la depuración no está habilitada, las declaraciones de depuración se ignoran), pero cuando tengo tiempo Lo actualizaré para exponerlos para que usted pueda hacer las comprobaciones usted mismo. Esto evitará que se realicen evaluaciones cuando no deberían, por ejemplo:

Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

Esto se convertirá en:

if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

(Ahorre un poco de tiempo de execusión)

De forma predeterminada, iniciamos sesión en dos ubicaciones:

1. Sistema de archivos del sitio web (en una extensión de archivo no servida)
2. Envío de correo electrónico por error y fatal

Los archivos se realizan en rollo de cada día o 10 mb (IIRC). No utilizamos el EventLog ya que puede requerir una mayor seguridad de la que solemos dar a un sitio.

Encuentro que el Bloc de notas funciona bien para leer los registros.

Answer 9

¿Qué marcos usas?

Utilizamos una combinación del bloque de aplicaciones de registro y un asistente de registro personalizado que funciona en torno a los bits de la estructura .Net. El LAB está configurado para generar archivos de registro bastante extensos que incluyen archivos de seguimiento generales separados para la entrada / salida del método de servicio y archivos de error específicos para problemas inesperados. La configuración incluye fecha / hora, hilo, pID, etc. para asistencia de depuración, así como el detalle completo de la excepción y la pila (en el caso de una excepción inesperada).

El asistente de registro personalizado utiliza Trace.Correlation y es particularmente útil en el contexto del registro en WF. Por ejemplo, tenemos una máquina de estado que invoca una serie de flujos de trabajo secuenciales. En cada una de estas actividades de invocación, registramos el inicio (utilizando StartLogicalOperation) y luego, al final, detenemos la operación lógica con un controlador de eventos de devolución gereric.

Esto ha demostrado ser útil varias veces al intentar depurar fallas en secuencias de negocios complejas, ya que nos permite determinar cosas como las decisiones de rama Si / Else, etc. más rápidamente en función de la secuencia de ejecución de la actividad.

¿Qué salidas de registro utilizas?

Usamos archivos de texto y archivos XML. Los archivos de texto se configuran a través del bloque de aplicaciones, pero también tenemos salidas XML de nuestro servicio WF. Esto nos permite capturar los eventos de tiempo de ejecución (persistencia, etc.) así como las excepciones genéricas de tipo de negocio. Los archivos de texto son registros continuos que se procesan por día y tamaño (creo que el tamaño total de 1 MB es un punto de renovación).

¿Qué herramientas utilizas para ver los registros?

Estamos usando Notepad y WCF Service Trace Viewer dependiendo del grupo de salida que estemos viendo. WCF Service Trace Viewer es realmente útil si tiene la configuración de salida correcta y puede hacer que la lectura de la salida sea mucho más sencilla. Dicho esto, si sé aproximadamente dónde está el error de todos modos, también es bueno leer un archivo de texto bien anotado.

Los registros se envían a un único directorio que luego se divide en subdirectores según el servicio de origen. El directorio raíz se expone a través de un sitio web cuyo acceso está controlado por un grupo de usuarios de soporte. Esto nos permite echar un vistazo a los registros de producción sin tener que realizar solicitudes y pasar por largos procesos de burocracia para los datos de producción.

Answer 10

Actualización: para las extensiones de System.Diagnostics, que proporcionan algunos de los oyentes faltantes que puede desear, consulte Essential.Diagnostics en CodePlex ( http://essentialdiagnostics.codeplex.com/ )

Marcos

P: ¿Qué marcos usas?

A: System.Diagnostics.TraceSource, integrado en .NET 2.0.

Proporciona un registro de aplicaciones potente, flexible y de alto rendimiento; sin embargo, muchos desarrolladores no son conscientes de sus capacidades y no las aprovechan al máximo.

Hay algunas áreas donde la funcionalidad adicional es útil, o a veces la funcionalidad existe pero no está bien documentada, sin embargo, esto no significa que todo el marco de registro (que está diseñado para ser extensible) debe desecharse y reemplazarse por completo como algunas alternativas populares. (NLog, log4net, Common.Logging e incluso EntLib Logging).

En lugar de cambiar la forma en que agrega sentencias de registro a su aplicación y reinventar la rueda, simplemente extienda el marco de Diagnóstico del Sistema en los pocos lugares donde lo necesite.

Me parece que los otros marcos, incluso EntLib, simplemente sufren el Síndrome de No Inventado Aquí, y creo que han perdido el tiempo reinventando los conceptos básicos que ya funcionan perfectamente en System.Diagnostics (como la forma en que se escriben las declaraciones de registro), En lugar de llenar los pocos huecos que existen. En resumen, no los uses, no son necesarios.

Características que quizás no conozcas:

• El uso de las sobrecargas de TraceEvent que toman una cadena de formato y argumentos puede ayudar al rendimiento ya que los parámetros se mantienen como referencias separadas hasta después de que Filter.ShouldTrace () haya tenido éxito. Esto significa que no se realizarán llamadas costosas a ToString () sobre los valores de los parámetros hasta que el sistema haya confirmado el mensaje.
• El Trace.CorrelationManager le permite correlacionar las declaraciones de registro sobre la misma operación lógica (ver más abajo).
• VisualBasic.Logging.FileLogTraceListener es bueno para escribir en archivos de registro y admite la rotación de archivos. Aunque en el espacio de nombres de VisualBasic, se puede usar con la misma facilidad en un proyecto de C # (u otro idioma) simplemente al incluir la DLL.
• Cuando usa EventLogTraceListener si llama a TraceEvent con múltiples argumentos y con una cadena de formato vacía o nula, los argumentos se pasan directamente al EventLog.WriteEntry () si está usando recursos de mensajes localizados.
• La herramienta Service Trace Viewer (de WCF) es útil para ver gráficos de archivos de registro correlacionados de actividad (incluso si no está usando WCF). Esto realmente puede ayudar a depurar problemas complejos donde se involucran múltiples subprocesos / actividades.
• Evite los gastos generales borrando todos los oyentes (o eliminando el valor predeterminado); de lo contrario, el valor predeterminado pasará todo al sistema de rastreo (e incurrirá en todos esos gastos generales ToString ()).

Áreas que podría querer ver en la extensión (si es necesario):

• Detector de rastreo de base de datos
• Oyente de traza de consola de color
• Escuchas de seguimiento de MSMQ / Email / WMI (si es necesario)
• Implementar un FileSystemWatcher para llamar a Trace.Refresh para cambios de configuración dinámicos

Otras recomendaciones:

Use los identificadores de eventos estructurados y mantenga una lista de referencia (por ejemplo, documéntelos en una enumeración).

Tener identificaciones de eventos únicas para cada evento (significativo) en su sistema es muy útil para correlacionar y encontrar problemas específicos. Es fácil rastrear de nuevo al código específico que registra / utiliza los identificadores de eventos, y puede facilitar la guía para errores comunes, por ejemplo, el error 5178 significa que la cadena de conexión de su base de datos es incorrecta, etc.

Los identificadores de eventos deben seguir algún tipo de estructura (similar a la teoría de los códigos de respuesta utilizados en el correo electrónico y HTTP), que le permite tratarlos por categoría sin conocer códigos específicos.

por ejemplo, el primer dígito puede detallar la clase general: 1xxx puede usarse para operaciones de ''Inicio'', 2xxx para el comportamiento normal, 3xxx para el seguimiento de la actividad, 4xxx para advertencias, 5xxx para los errores, 8xxx para operaciones de ''Detener'', 9xxx para errores fatales etc.

El segundo dígito puede detallar el área, por ejemplo, 21xx para información de base de datos (41xx para advertencias de base de datos, 51xx para errores de base de datos), 22xx para modo de cálculo (42xx para advertencias de cálculo, etc.), 23xx para otro módulo, etc.

Los ID de eventos asignados y estructurados también le permiten usarlos en los filtros.

P: Si utiliza el rastreo, ¿utiliza Trace.Correlation.StartLogicalOperation?

R: Trace.CorrelationManager es muy útil para correlacionar sentencias de registro en cualquier tipo de entorno de subprocesos múltiples (que es prácticamente cualquier cosa en estos días).

Necesita al menos establecer el ActivityId una vez para cada operación lógica con el fin de correlacionar.

Start / Stop y LogicalOperationStack se pueden usar para un simple contexto basado en la pila. Para contextos más complejos (por ejemplo, operaciones asíncronas), el uso de TraceTransfer al nuevo ActivityId (antes de cambiarlo), permite la correlación.

La herramienta Service Trace Viewer puede ser útil para ver gráficos de actividad (incluso si no está usando WCF).

P: ¿Escribes este código manualmente, o usas algún tipo de programación orientada a aspectos para hacerlo? ¿Quieres compartir un fragmento de código?

R: Es posible que desee crear una clase de ámbito, por ejemplo, LogicalOperationScope, que (a) configura el contexto cuando se crea y (b) restablece el contexto cuando se elimina.

Esto le permite escribir código como el siguiente para envolver las operaciones automáticamente:

 using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
{
// .. do work here
}

En la creación, el ámbito podría primero establecer ActivityId si fuera necesario, llamar a StartLogicalOperation y luego registrar un mensaje TraceEventType.Start. En Desechar, podría registrar un mensaje de detención y luego llamar a StopLogicalOperation.

P: ¿Proporciona alguna forma de granularidad sobre las fuentes de rastreo? Por ejemplo, WPF TraceSources le permite configurarlos en varios niveles.

R: Sí, múltiples fuentes de rastreo son útiles / importantes a medida que los sistemas se hacen más grandes.

Si bien es probable que desee registrar de manera consistente todas las advertencias y las anteriores, o todas las informaciones y los mensajes anteriores, para un sistema de tamaño razonable, el volumen de la actividad de seguimiento (inicio, detención, etc.) y el registro detallado simplemente se vuelven demasiado.

En lugar de tener un solo interruptor que lo encienda o apague, es útil poder activar esta información para una sección de su sistema a la vez.

De esta manera, puede localizar problemas significativos del registro general (todas las advertencias, errores, etc.), y luego hacer "zoom" en las secciones que desee y establecerlas en Seguimiento de actividad o incluso en niveles de depuración.

La cantidad de orígenes de rastreo que necesita depende de su aplicación, por ejemplo, es posible que desee un origen de rastreo por ensamblaje o por sección principal de su aplicación.

Si necesita un control aún más preciso, agregue interruptores booleanos individuales para activar / desactivar el rastreo de alto volumen específico, por ejemplo, volcados de mensajes sin procesar. (O podría usarse una fuente de rastreo separada, similar a WCF / WPF).

Es posible que también desee considerar orígenes de seguimiento separados para el Seguimiento de actividad frente al registro general (otro), ya que puede hacer que sea un poco más fácil configurar los filtros exactamente como los quiere.

Tenga en cuenta que los mensajes aún se pueden correlacionar a través de ActivityId incluso si se usan fuentes diferentes, así que use tantas como necesite.

Oyentes

P: ¿Qué salidas de registro utilizas?

Esto puede depender de qué tipo de aplicación está escribiendo y qué cosas se están registrando. Por lo general, las cosas diferentes van en diferentes lugares (es decir, múltiples salidas).

Generalmente clasifico los resultados en tres grupos:

(1) Eventos - Registro de eventos de Windows (y archivos de rastreo)

por ejemplo, si está escribiendo un servidor / servicio, la mejor práctica en Windows es usar el Registro de eventos de Windows (no tiene una IU para la cual informar).

En este caso, todos los eventos Fatal, Error, Advertencia e Información (nivel de servicio) deben ir al Registro de eventos de Windows. El nivel de información debe reservarse para este tipo de eventos de alto nivel, los que desea incluir en el registro de eventos, por ejemplo, "Servicio iniciado", "Servicio detenido", "Conectado a Xyz" y quizás incluso "Programación iniciada" , "Usuario conectado", etc.

En algunos casos, es posible que desee que la escritura en el registro de eventos sea una parte integrada de su aplicación y no a través del sistema de seguimiento (es decir, escriba las entradas del Registro de eventos directamente). Esto significa que no se puede apagar accidentalmente. (Tenga en cuenta que también desea anotar el mismo evento en su sistema de seguimiento para poder correlacionar).

En contraste, una aplicación de Windows GUI generalmente informaría esto al usuario (aunque también pueden iniciar sesión en el Registro de eventos de Windows).

Los eventos también pueden tener contadores de rendimiento relacionados (p. Ej., Número de errores / seg), y puede ser importante coordinar cualquier escritura directa en el Registro de eventos, contadores de rendimiento, escribir en el sistema de seguimiento e informar al usuario para que ocurran en al mismo tiempo.

es decir, si un usuario ve un mensaje de error en un momento determinado, debería poder encontrar el mismo mensaje de error en el Registro de eventos de Windows y luego el mismo evento con la misma marca de tiempo en el registro de seguimiento (junto con otros detalles de seguimiento).

(2) Actividades: archivos de registro de aplicación o tabla de base de datos (y archivos de rastreo)

Esta es la actividad regular que realiza un sistema, por ejemplo, la página web servida, el mercado bursátil registrado, el pedido recibido, el cálculo realizado, etc.

El seguimiento de la actividad (inicio, detención, etc.) es útil aquí (en la mayoría correcta).

Además, es muy común utilizar un registro de aplicación específico (a veces llamado un registro de auditoría). Por lo general, esta es una tabla de base de datos o un archivo de registro de la aplicación y contiene datos estructurados (es decir, un conjunto de campos).

Las cosas pueden ponerse un poco borrosas aquí dependiendo de su aplicación. Un buen ejemplo podría ser un servidor web que escribe cada solicitud en un registro web; ejemplos similares podrían ser un sistema de mensajería o un sistema de cálculo donde cada operación se registra junto con detalles específicos de la aplicación.

Un ejemplo no tan bueno es el mercado de valores o un sistema de pedidos de ventas. En estos sistemas, probablemente ya esté registrando la actividad, ya que tienen un valor comercial importante, sin embargo, el principio de correlacionarlos con otras acciones sigue siendo importante.

Además de los registros de aplicaciones personalizados, las actividades también suelen tener contadores de rendimiento relacionados, por ejemplo, el número de transacciones por segundo.

En general, debe coordinar el registro de actividades en diferentes sistemas, es decir, escribir en el registro de la aplicación al mismo tiempo que aumenta el contador de rendimiento y el registro en el sistema de seguimiento. Si lo hace todo al mismo tiempo (o uno detrás de otro en el código), entonces los problemas de depuración son más fáciles (que si todos ocurren en diferentes momentos / ubicaciones en el código).

(3) Rastreo de depuración: archivo de texto, o quizás XML o base de datos.

Esta es información a nivel detallado y más bajo (por ejemplo, interruptores booleanos personalizados para activar / desactivar volcados de datos sin procesar). Esto proporciona las agallas o detalles de lo que hace un sistema en un nivel de subactividad.

Este es el nivel que desea poder activar / desactivar para secciones individuales de su aplicación (de ahí las múltiples fuentes). No quieres que estas cosas abarroten el registro de eventos de Windows. Algunas veces se usa una base de datos, pero lo más probable es que los archivos de registro estén borrados después de un cierto tiempo.

Una gran diferencia entre esta información y un archivo de registro de aplicación es que no está estructurado. Mientras que un Registro de aplicación puede tener campos para A, De, Cantidad, etc., los rastreos de depuración detallados pueden ser lo que el programador ingrese, por ejemplo, "verificando valores X = {valor}, Y = falso", o comentarios / marcadores aleatorios como " Hecho, intentando de nuevo ".

Una práctica importante es asegurarse de que las cosas que coloque en los archivos de registro de la aplicación o el Registro de eventos de Windows también se registren en el sistema de rastreo con los mismos detalles (por ejemplo, la marca de tiempo). Esto le permite luego correlacionar los diferentes registros al investigar.

Si planea usar un visor de registro particular porque tiene una correlación compleja, por ejemplo, el Visor de seguimiento de servicios, entonces necesita usar un formato apropiado, es decir, XML. De lo contrario, un simple archivo de texto suele ser lo suficientemente bueno: en los niveles inferiores, la información está en gran parte desestructurada, por lo que puede encontrar volcados de matrices, volcados de pila, etc. Siempre que pueda correlacionarse con registros más estructurados en niveles superiores, todo debería estar bien.

P: Si usa archivos, ¿utiliza registros rotativos o solo un archivo? ¿Cómo se hacen los registros disponibles para que la gente los consuma?

R: En el caso de los archivos, generalmente se desean archivos de registro móviles desde un punto de vista de capacidad de administración (con System.Diagnostics simplemente use VisualBasic.Logging.FileLogTraceListener).

La disponibilidad de nuevo depende del sistema. Si solo está hablando de archivos, entonces para un servidor / servicio, solo se puede acceder a los archivos rodantes cuando sea necesario. (El registro de eventos de Windows o los registros de aplicaciones de base de datos tendrían sus propios mecanismos de acceso).

Si no tiene un acceso fácil al sistema de archivos, entonces el rastreo de depuración en una base de datos puede ser más fácil. [es decir, implementar una base de datos TraceListener].

Una solución interesante que vi para una aplicación GUI de Windows fue que registraba información de seguimiento muy detallada en un "registrador de vuelo" mientras se ejecutaba y luego, cuando la apagabas, si no tenía problemas, simplemente eliminaba el archivo.

Si, sin embargo, se bloqueó o encontró un problema, entonces el archivo no se eliminó. Ya sea que detecte el error, o la próxima vez que lo ejecute, notará el archivo y luego podrá tomar medidas, por ejemplo, comprimirlo (por ejemplo, 7zip) y enviarlo por correo electrónico o, de lo contrario, ponerlo a disposición.

Muchos sistemas en estos días incorporan informes automatizados de fallas a un servidor central (después de verificar con los usuarios, por ejemplo, por razones de privacidad).

Visita

P: ¿Qué herramientas utiliza para ver los registros?

R: Si tiene varios registros por diferentes motivos, utilizará varios visores.

Notepad / vi / Notepad ++ o cualquier otro editor de texto es el básico para los registros de texto sin formato.

Si tiene operaciones complejas, por ejemplo, actividades con transferencias, entonces, obviamente, usaría una herramienta especializada como el Visor de rastreo de servicios. (Pero si no lo necesitas, entonces un editor de texto es más fácil).

Como generalmente registro información de alto nivel en el Registro de eventos de Windows, proporciona una forma rápida de obtener una visión general, de manera estructurada (busque los iconos de advertencia / error). Solo necesita comenzar a buscar archivos de texto si no hay suficiente en el registro, aunque al menos el registro le da un punto de partida. (En este punto, asegurarse de que sus registros tengan coordenadas coordinadas se vuelve útil).

En general, el registro de eventos de Windows también hace que estos eventos importantes estén disponibles para las herramientas de monitoreo como MOM u OpenView.

Otros --

Si inicia sesión en una base de datos, puede ser fácil filtrar y clasificar la información (por ejemplo, ampliar una identificación de actividad en particular. (Con archivos de texto puede usar Grep / PowerShell o similar para filtrar en el GUID particular que desee)

MS Excel (u otro programa de hoja de cálculo). Esto puede ser útil para analizar información estructurada o semiestructurada si puede importarla con los delimitadores correctos para que los diferentes valores vayan en columnas diferentes.

Cuando ejecuto un servicio en debug / test, por lo general lo alojo en una aplicación de consola por simplicidad, encuentro útil un registrador de consola de color (por ejemplo, rojo para errores, amarillo para advertencias, etc.). Es necesario implementar un escucha de seguimiento personalizado.

Tenga en cuenta que el marco no incluye un registrador de consola de color o un registrador de base de datos, por lo que, en este momento, deberá escribirlos si los necesita (no es demasiado difícil).

Realmente me molesta que varios frameworks (log4net, EntLib, etc.) hayan perdido el tiempo reinventando la rueda y reimplementado el registro básico, el filtrado y el registro en archivos de texto, el Registro de eventos de Windows y los archivos XML, cada uno por su cuenta. diferente manera (las declaraciones de registro son diferentes en cada uno); cada uno ha implementado su propia versión de, por ejemplo, un registrador de base de datos, cuando la mayor parte de eso ya existía y todo lo que se necesitaba era un par de escuchas de rastreo más para System.Diagnostics. Hable acerca de un gran desperdicio de esfuerzo duplicado.

P: Si está creando una solución ASP.NET, ¿también utiliza ASP.NET Health Monitoring? ¿Incluyes la salida de seguimiento en los eventos del monitor de estado? ¿Qué pasa con Trace.axd?

Estas cosas se pueden activar / desactivar según sea necesario. Considero que Trace.axd es bastante útil para depurar cómo responde un servidor a ciertas cosas, pero generalmente no es útil en un entorno muy utilizado o para el rastreo a largo plazo.

P: ¿Qué pasa con los contadores de rendimiento personalizados?

Para una aplicación profesional, especialmente un servidor / servicio, espero verla completamente instrumentada con los contadores del Monitor de rendimiento y el registro en el Registro de eventos de Windows. Estas son las herramientas estándar en Windows y deben usarse.

Debe asegurarse de incluir instaladores para los contadores de rendimiento y los registros de eventos que utiliza; estos deben crearse en el momento de la instalación (al instalar como administrador). Cuando su aplicación se ejecuta normalmente, no debería tener privilegios de administración (por lo que no podrá crear registros faltantes).

Esta es una buena razón para practicar el desarrollo como no administrador (tenga una cuenta de administrador separada para cuando necesite instalar servicios, etc.). Si escribe en el registro de eventos, .NET creará automáticamente un registro faltante la primera vez que lo escriba; Si se desarrolla como no administrador, detectará esto temprano y evitará una sorpresa desagradable cuando un cliente instala su sistema y luego no puede usarlo porque no se está ejecutando como administrador.