.net mejores practicas de diagnostico?

system.diagnostics

Question

Inicialmente, no usamos ningún registro ni depuración, pero después de pasar algunas semanas para rastrear algunos daños en los datos, decidimos poner Debug.Write y Trace necesarios para producción y Debug.Assert

Así que ahora la pregunta es ¿Cuál es la mejor práctica para usar el registro de seguimiento y depuración? Sólo estoy buscando algo genérico.

public void AddRectodatabase(object record)
{
Debug.WriteLine(record.ToString());
Trace.WriteLine(record.ToString());
// Add it to databse
Debug.Assert(true, "Use this on case by case basis");
}

¿Es esto lo suficientemente bueno para un propósito general, estoy haciendo algo mal allí?

Queremos mantenernos en .net System.Diagnostics sobre otras alternativas como log4net.

¿Hay algo más útil en System.Diagnostics?

Answer 1

Debe planear aumentar los eventos de rastreo de ETW en su aplicación, no solo para alertar a los oyentes sobre los problemas, sino también para proporcionar visibilidad del comportamiento e incluso del rendimiento del rendimiento de sus aplicaciones y componentes.

ETW es una forma (increíblemente) de alto rendimiento y (sorprendentemente) bajo impacto para generar eventos que se pueden recopilar y analizar, incluso en entornos de producción. Es la infraestructura de registro y seguimiento utilizada en Windows, SQL, etc.

Tres enlaces útiles para ti:

1. Diagnóstico: uso del rastreo de ETW en .NET 3.5 (EventProviderTraceListener)
2. Controlando el texto del enlace de .NET Framework Logging
3. Ejercicio de dos minutos: Introducción a XPerf

Lea los 3 en orden y luego vuelva a leerlos; la información posterior será muy útil, pero será más difícil de entender a menos que primero comprenda los conceptos básicos;) Ignore las instrucciones de usar logman para iniciar y detener sus colecciones de rastreo; use XPerf en su lugar.

Si aún no has visto el kit de herramientas de Perf y el visor de XPerf , ¡entonces te espera una sorpresa ! :RE

Le recomiendo encarecidamente que considere crear eventos de inicio y detención al comienzo y al final de todas las funciones más importantes de sus aplicaciones para que pueda superponer estos eventos con otros telemetría para que pueda ver, por ejemplo, el impacto de sus funciones. En Disco, Red, Memoria, CPU, etc.

Espero que esto ayude.

Answer 2

Esta respuesta es tarde, pero ...

Creo que deberías considerar usar TraceSources en lugar de Debug.WriteLine y / o Trace.WriteLine. Con TraceSources, puede lograr un mayor nivel de control sobre su registro. El nivel de cada TraceSource puede controlarse, al igual que el destino de TraceSource (TraceListener). Puedes escribir código como este:

public class RectToSqlServer : IDatabaseUtilities
{
private static readonly TraceSource ts = new TraceSource("RectToSqlServer");
public void AddRectToDatabase(object record)
{
ts.TraceEvent(TraceEventType.Information, "record = {0}", record.ToString());
//Add record to database ...
}
}
public class RectToOracle : IDatabaseUtilities
{
private static readonly TraceSource ts = new TraceSource("RectToOracleServer");
public void AddRectToDatabase(object record)
{
ts.TraceEvent(TraceEventType.Information, "record = {0}", record.ToString());
//Add record to database ...
}
}

Ahora, puede controlar el registro (nivel, destino, etc.) para cada clase de forma independiente. Además, tenga en cuenta que no tiene que agregar Trace.WriteLine y Debug.WriteLine para obtener el inicio de sesión en las versiones de depuración y de versión. El uso de TraceSources lo colocará en una buena posición para usar ETW en el futuro, ya que hay un ETWTraceListener disponible a partir de .NET (quizás 3.5, sin duda en 4.0). PERO esta funcionalidad ETW en particular solo está disponible en Vista y sistemas operativos posteriores.

Para agregar capacidad a System.Diagnostics (principalmente, quizás solo, si se está registrando a través de TraceSource), consulte Ukadc.Diagnostics . Ukadc.Diagnostics agrega una capacidad de formato bastante interesante (similar a lo que puedes hacer con log4net y NLog) a System.Diagnostics. No hay dependencia de código (solo instale Ukadc.Diagnostics y agregue alguna configuración a su app.config). Tengo que decir que creo que es realmente genial.

Si desea hacer un poco de trabajo para envolver su acceso a TraceSources, vea here una interesante implementación de un contenedor de TraceSource que esencialmente le da a TraceSources la capacidad de "heredar" la configuración de registro de "antecesores" de TraceSources (por ejemplo, cómo log4net y NLog loggers puede heredar la configuración de registro).

Answer 3

Lo estás usando bien, excepto para Assert con el primer argumento codificado en true . Probablemente debería agregar alguna condición allí y el mensaje (segundo argumento) se imprimirá solo si la condición es falsa. Así que en su ejemplo de código nunca se mostrará. En algunos casos, WriteLineIf puede ser útil si no desea ajustar sus declaraciones de depuración en bloques condicionales.

Echa un vistazo a la referencia de clase de depuración que tiene bastantes métodos y propiedades útiles para ayudarte a registrar cosas.

Answer 4

System.Diagnostics también contiene EventLog.WriteEntry, pero es posible que desee o no inundar el EventLog con mensajes de seguimiento, aunque es una forma fácil de registrar los principales eventos de la aplicación.