Actualización: para las extensiones de System.Diagnostics, que proporcionan algunos de los oyentes que faltan, puede consultar Essential.Diagnostics en CodePlex ( http://essentialdiagnostics.codeplex.com/ )
Marcos
P: ¿Qué marcos utilizas?
R: System.Diagnostics.TraceSource, integrado en .NET 2.0.
Proporciona un registro potente, flexible y de alto rendimiento para aplicaciones, sin embargo, muchos desarrolladores no son conscientes de sus capacidades y no las utilizan por completo.
Hay algunas áreas donde la funcionalidad adicional es útil, o a veces existe la funcionalidad pero no está bien documentada, sin embargo, esto no significa que todo el marco de registro (que está diseñado para ser extensible) deba desecharse y reemplazarse por completo como algunas alternativas populares. (NLog, log4net, Common.Logging e incluso EntLib Logging).
En lugar de cambiar la forma de agregar declaraciones de registro a su aplicación y reinventar la rueda, simplemente extendió el marco System.Diagnostics en los pocos lugares donde lo necesita.
Me parece que los otros marcos, incluso EntLib, simplemente padecen el Síndrome No Inventado Aquí, y creo que han perdido el tiempo reinventando los conceptos básicos que ya funcionan perfectamente en el Sistema. en lugar de llenar los pocos vacíos que existen. En resumen, no los use, no son necesarios.
Características que quizás no conocías:
- El uso de las sobrecargas de TraceEvent que toman una cadena de formato y argumentos pueden ayudar al rendimiento ya que los parámetros se mantienen como referencias separadas hasta que Filter.ShouldTrace () haya tenido éxito. Esto significa que no hay llamadas costosas a ToString () en los valores de los parámetros hasta que el sistema haya confirmado que el mensaje se registrará realmente.
- Trace.CorrelationManager le permite correlacionar 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 VisualBasic, se puede usar con la misma facilidad en un proyecto de C # (u otro lenguaje) simplemente al incluir la DLL.
- Cuando utiliza EventLogTraceListener si llama a TraceEvent con múltiples argumentos y con una cadena de formato vacía o nula, los argumentos se pasan directamente a EventLog.WriteEntry () si está utilizando recursos de mensajes localizados.
- La herramienta Service Trace Viewer (de WCF) es útil para ver gráficos de archivos de registro correlacionados con actividad (incluso si no está usando WCF). Esto realmente puede ayudar a depurar problemas complejos en los que intervienen múltiples hilos / actividades.
- Evite los gastos generales borrando todos los oyentes (o eliminando los valores predeterminados); de lo contrario, Default pasará todo al sistema de rastreo (e incurrirá en todos esos gastos generales de ToString ()).
Áreas que tal vez quiera mirar extendiendo (si es necesario):
- Escucha de rastreo de base de datos
- Oyente de seguimiento de consola de color
- MSMQ / Email / WMI oyentes de seguimiento (si es necesario)
- Implemente un FileSystemWatcher para llamar a Trace.Refresh para cambios dinámicos de configuración
Otras recomendaciones
Use identificadores de eventos estructurados y mantenga una lista de referencia (por ejemplo, documente en una enumeración).
Tener identificadores de eventos únicos para cada evento (significativo) en su sistema es muy útil para correlacionar y encontrar problemas específicos. Es fácil rastrear el código específico que registra / usa los identificadores de eventos, y puede facilitar la orientación de errores comunes, por ejemplo, el error 5178 significa que la cadena de conexión de la 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 utilizada 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 se puede usar para operaciones de 'Inicio', 2xxx para comportamiento normal, 3xxx para seguimiento de actividad, 4xxx para advertencias, 5xxx para errores, 8xxx para operaciones de 'Parada', 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 identificadores de eventos estructurados y asignados también le permiten usarlos en filtros.
P: Si utiliza el rastreo, ¿utiliza Trace.Correlation.StartLogicalOperation?
R: Trace.CorrelationManager es muy útil para correlacionar declaraciones 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 para correlacionar.
Start / Stop y LogicalOperationStack se pueden usar para un contexto simple basado en la pila. Para contextos más complejos (por ejemplo, operaciones asincrónicas), 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: ¿Escribe este código manualmente o utiliza alguna forma 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 ajustar automáticamente las operaciones:
using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
{
// .. do work here
}
En la creación, el alcance podría establecer primero ActivityId si fuera necesario, llamar a StartLogicalOperation y luego registrar un mensaje TraceEventType.Start. En Dispose, podría registrar un mensaje Stop y luego llamar a StopLogicalOperation.
P: ¿Proporcionan alguna forma de granularidad sobre las fuentes de rastreo? Por ejemplo, WPF TraceSources le permite configurarlos en varios niveles.
R: Sí, las Fuentes de rastreo múltiples son útiles / importantes a medida que los sistemas se hacen más grandes.
Si bien es probable que desee registrar constantemente todos los mensajes de Advertencia y superior, o toda la Información y superior, para cualquier sistema de tamaño razonable, el volumen de Rastreo de actividad (Inicio, Parada, etc.) y el registro detallado simplemente se vuelve demasiado.
En lugar de tener solo un interruptor que lo encienda o apague todo, es útil poder encender esta información para una sección de su sistema a la vez.
De esta manera, puede localizar problemas importantes desde el inicio de sesión habitual (todas las advertencias, errores, etc.) y luego "acercar" las secciones que desee y establecerlas en el Rastreo de actividad o incluso en los niveles de Depuración.
El número de fuentes de rastreo que necesita depende de su aplicación, por ejemplo, puede querer una fuente 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 seguimiento 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).
También es posible que desee considerar fuentes de rastreo separadas para el rastreo de actividad frente al registro general (otro), ya que puede facilitar un poco la configuración de los filtros exactamente como los desea.
Tenga en cuenta que los mensajes aún pueden correlacionarse a través de ActivityId, incluso si se utilizan diferentes fuentes, por lo tanto, use tantos 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, diferentes cosas 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 seguimiento)
Por ejemplo, si escribe un servidor / servicio, la mejor práctica en Windows es usar el Registro de eventos de Windows (no tiene una IU para informar).
En este caso, todos los eventos Fatales, Error, Advertencia e Información (de 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" e incluso "Programa iniciado". , "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 directamente las entradas del Registro de eventos). Esto significa que no se puede apagar accidentalmente. (Tenga en cuenta que también desea tener en cuenta el mismo evento en su sistema de rastreo para que pueda correlacionarse).
En contraste, una aplicación GUI de Windows generalmente informaría esto al usuario (aunque también puede iniciar sesión en el Registro de eventos de Windows).
Los eventos también pueden tener contadores de rendimiento relacionados (por ejemplo, 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 rastreo 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 aplicaciones o tabla de base de datos (y archivos de rastreo)
Esta es la actividad regular que realiza un sistema, por ejemplo, página web servida, comercio de bolsa alojado, orden tomada, cálculo realizado, etc.
El seguimiento de actividad (inicio, detención, etc.) es útil aquí (en la granualidad correcta).
Además, es muy común usar un registro de aplicación específico (a veces llamado 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 pueden 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 son las operaciones bursátiles 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 a menudo también tienen contadores de rendimiento relacionados, por ejemplo, número de transacciones por segundo.
En general, debe coordinar el registro de actividades en diferentes sistemas, es decir, escribir en el registro de su aplicación al mismo tiempo que aumenta su contador de rendimiento e inicia sesión en su sistema de rastreo. Si lo hace todo al mismo tiempo (o directamente uno después del 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 tal vez XML o base de datos.
Esta es información a nivel detallado e inferior (por ejemplo, interruptores booleanos personalizados para activar / desactivar volcados de datos sin procesar). Esto proporciona las agallas o detalles de lo que está haciendo un sistema a nivel de sub-actividad.
Este es el nivel que desea poder activar / desactivar para secciones individuales de su aplicación (de ahí las múltiples fuentes). No desea que estas cosas llenen el Registro de eventos de Windows. A veces se usa una base de datos, pero lo más probable es que se acumulen archivos de registro que se purgan 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, desde, cantidad, etc., los rastreos detallados de depuración pueden ser cualquier cosa que un programador ponga, por ejemplo, "verificar 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 en el Registro de eventos de Windows también se registren en el sistema de rastreo con los mismos detalles (por ejemplo, marca de tiempo). Esto le permite correlacionar los diferentes registros al investigar.
Si está planeando usar un visor de registro particular porque tiene una correlación compleja, por ejemplo, el Visor de rastreo de servicio, entonces necesita usar un formato apropiado, es decir, XML. De lo contrario, un archivo de texto simple 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 correlacionar de nuevo a registros más estructurados en niveles superiores, las cosas deberían estar bien.
P: Si utiliza archivos, ¿utiliza registros continuos o solo un archivo? ¿Cómo haces que los registros estén disponibles para que la gente los consuma?
R: Para los archivos, generalmente desea rodar archivos de registro desde el punto de vista de la capacidad de administración (con System.Diagnostics simplemente use VisualBasic.Logging.FileLogTraceListener).
La disponibilidad nuevamente 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. (Windows Event Log o Database Application Logs tendrían sus propios mecanismos de acceso).
Si no tiene fácil acceso al sistema de archivos, entonces el rastreo de depuración a 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 rastreo muy detallada en un "registrador de vuelo" mientras se ejecutaba y luego, cuando la apagaba si no tenía problemas, simplemente borraba el archivo.
Sin embargo, si se bloqueó o encontró un problema, el archivo no se eliminó. Si detecta el error o la próxima vez que lo ejecuta, notará el archivo y luego podrá tomar medidas, por ejemplo, comprimirlo (por ejemplo, 7zip) y enviarlo por correo electrónico o ponerlo a disposición de otra manera.
En la actualidad, muchos sistemas incorporan informes automáticos de fallas a un servidor central (después de consultar 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 razones, utilizará múltiples visores.
Notepad / vi / Notepad ++ o cualquier otro editor de texto es lo básico para los registros de texto sin formato.
Si tiene operaciones complejas, por ejemplo, actividades con transferencias, entonces, obviamente, utilizaría una herramienta especializada como Service Trace Viewer. (Pero si no lo necesita, 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 descripción general, de manera estructurada (busque los bonitos iconos de error / advertencia). Solo necesita comenzar a buscar archivos de texto si no hay suficiente en el registro, aunque al menos el registro le proporciona un punto de partida. (En este punto, asegurarse de que sus registros tengan entradas coordinadas se vuelve útil).
En general, el Registro de eventos de Windows también hace que estos eventos importantes estén disponibles para herramientas de monitoreo como MOM u OpenView.
Otros --
Si inicia sesión en una base de datos, puede ser fácil filtrar y ordenar la información (por ejemplo, acercar una identificación de actividad particular. (Con los 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 depuración / prueba, generalmente 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.). Debe implementar un escucha de rastreo 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, necesitaría escribirlos si los necesita (no es demasiado difícil).
Realmente me molesta que varios marcos (log4net, EntLib, etc.) hayan perdido el tiempo reinventando la rueda y re-implementando el registro básico, el filtrado y el registro en archivos de texto, el Registro de eventos de Windows y archivos XML, cada uno en su propio manera diferente (las declaraciones de registro son diferentes en cada una); 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 rastreadores más para System.Diagnostics. Hable sobre un gran desperdicio de esfuerzo duplicado.
P: Si está creando una solución ASP.NET, ¿también usa ASP.NET Health Monitoring? ¿Incluye resultados de seguimiento en los eventos del monitor de salud? ¿Qué pasa con Trace.axd?
Estas cosas se pueden activar / desactivar según sea necesario. Encuentro que Trace.axd es bastante útil para depurar la forma en que un servidor responde a ciertas cosas, pero generalmente no es útil en un entorno muy utilizado o para el seguimiento a largo plazo.
P: ¿Qué pasa con los contadores de rendimiento personalizados?
Para una aplicación profesional, especialmente un servidor / servicio, espero verla completamente equipada 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 (cuando se instala 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, lo detectará temprano y evitará una desagradable sorpresa cuando un cliente instale su sistema y luego no pueda usarlo porque no se está ejecutando como administrador.