.net ¿Mejores prácticas de diagnóstico?

Question

En principio no usamos ningún registro o seguimiento de depuración pero después de pasar unas semanas para rastrear hasta cierto grado de corrupción de datos que decidimos poner Debug.Write requerida y de seguimiento para la producción y Debug.Assert

Así que ahora la pregunta es ¿Cuál es la mejor práctica para usar el registro de depuración y rastreo. Solo 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 suficientemente bueno para propósitos generales, estoy haciendo algo mal allí?

Queremos seguir con .net System.Diagnostics sobre otras alternativas como log4net.

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

Answer 1

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

ETW es un (insanamente) alto rendimiento y (sorprendentemente) de bajo impacto para generar eventos que se pueden recopilar y analizar, incluso en entornos de producción. Es la infraestructura de registro & rastreo utilizado a lo largo de Windows, SQL, etc.

Tres enlaces útiles para usted:

1. Diagnostics: Using ETW tracing in .NET 3.5 (EventProviderTraceListener)
2. Controlling .NET Framework Logging link text
3. Two Minute Drill: Introduction to XPerf

Lea los 3 con el fin y luego vuelva a leer: la información posterior será muy útil, pero será más difícil de entender a menos que capte lo básico primero;) Ignore las instrucciones para usar logman para iniciar y detener sus colecciones de rastreo; use XPerf en su lugar.

Si aún no has visto the Perf toolkit and XPerf viewer, ¡estás de enhorabuena! : D

Creo firmementeanimo a considerar un aumento de iniciar & eventos parada en el inicio y el final de todas las funciones más importantes de tus aplicaciones para que pueda superponer estos eventos con otra telemetría para que pueda ver, por ejemplo, el impacto de sus características de aplicaciones en disco, red, memoria, CPU, etc.

Espero que esto ayude.

Answer 2

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

Echa un vistazo a Debug class reference que tiene bastantes métodos y propiedades útiles para ayudarte a registrar cosas.

Answer 3

System.Diagnostics también contiene EventLog.WriteEntry, pero puede o no desear inundar EventLog con mensajes de seguimiento, aunque es una manera fácil de registrar los principales eventos de la aplicación registrados.

Answer 4

Esta respuesta es tarde, pero ...

Creo que se debe considerar el uso 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 se puede controlar al igual que el destino de TraceSource (TraceListener). Puede 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, se puede controlar la explotación forestal (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 tanto en versiones de depuración como de versiones. El uso de TraceSources lo colocará en una buena posición para usar ETW en el futuro, ya que hay un ETWTraceListener disponible comenzando en .NET (quizás 3.5, sin duda por 4.0). PERO esta funcionalidad particular de ETW solo está disponible en Vista y sistemas operativos posteriores.

Para agregar capacidad a System.Diagnostics (principalmente - tal vez solo - si se registra a través de TraceSource), mira Ukadc.Diagnostics. Ukadc.Diagnostics agrega una capacidad de formateo muy buena (similar a lo que puede hacer con log4net y NLog) a System.Diagnostics. No hay dependencia del código (solo instale Ukadc.Diagnostics y agregue alguna configuración a su app.config). Debo decir que creo que es genial.

Si usted quiere poner en un poco de trabajo para envolver su acceso a TraceSources, ver here para una aplicación interesante de un envoltorio TraceSource que esencialmente da TraceSources la capacidad de "heredar" configuración de registro de TraceSources "antepasado" (como la forma de log4net y NLog Loggers pueden heredar la configuración de registro).