.net Рекомендации по диагностике?

Question

Мы изначально не использовали протоколирования или отладки трассировку, но, проведя несколько недель, чтобы проследить вниз некоторое искажение данных мы решили поставить требуемую Debug.Write и трассировка для производства и Debug.Assert

Так что теперь вопрос в том, что это наилучшей практикой использования отладки и отслеживания трассировки. Я просто ищу что-то общее.

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"); 
} 

Действительно ли это достаточно для общего назначения, я делаю что-то не так?

Мы хотим придерживаться .net System.Diagnostics над другими альтернативами, такими как log4net.

Есть ли еще что-нибудь полезное в System.Diagnostics?

Answer 1

Вам следует планировать воссоздание событий трассировки ETW во всем приложении - не только для оповещения слушателей о проблемах, но также для обеспечения видимости поведения и производительности ваших приложений и компонентов.

ETW - безумный высокопроизводительный и (удивительно) способ воздействия на события, который можно собрать и проанализировать, даже в производственных условиях. Это трассировка инфраструктура каротажа & используемой в Windows, SQL и т.д.

Три полезных ссылок для Вас:

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

Читать все 3 в порядке и затем перечитывать - более поздняя информация будет очень полезна, но будет сложнее понять, если вы не поймете основы сначала;) Игнорируйте инструкции, чтобы использовать logman для запуска и остановки ваших коллекций трассировок; вместо этого используйте XPerf.

Если вы еще не видели the Perf toolkit and XPerf viewer, тогда вы в угоду! : D

Я сильно призываю вас рассмотреть вопрос о повышении начать & стопы-события в начале и в конце всех наиболее важных особенностей ваших приложений, так что вы можете наложить эти события с другой телеметрией, так что вы можете видеть, для например, влияние ваших функций приложений на диск, сеть, память, процессор и т. д.

Надеюсь, это поможет.

Answer 2

Вы используете его отлично, за исключением Assert с первым аргументом, жестко закодированным до true. Вероятно, вы должны добавить какое-то условие, и сообщение (второй аргумент) будет напечатано, только если условие ложно. Поэтому в вашем примере кода он никогда не будет отображаться. В некоторых случаях WriteLineIf может пригодиться, если вы не хотите обертывать свои отладочные операторы в условных блоках.

Отъезд Debug class reference В нем есть несколько полезных методов и свойств, которые помогут вам регистрировать вещи.

Answer 3

System.Diagnostics также содержит EventLog.WriteEntry, но вы можете или не хотите наводнять EventLog сообщениями трассировки, хотя это простой способ получить основные события приложений, регистрируемые.

Answer 4

Этот ответ запаздывает, но ...

Я думаю, вы должны рассмотреть возможность использования TraceSources, а не Debug.WriteLine и/или Trace.WriteLine. С помощью TraceSources вы можете добиться более высокого уровня контроля за протоколированием. Уровень каждого TraceSource можно контролировать, как и пункт назначения TraceSource (TraceListener). Вы можете написать код так:

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 ... 

    } 
} 

Теперь вы можете контролировать ведение журнала (уровень, пункт назначения и т.д.) для каждого класса независимо друг от друга. Кроме того, обратите внимание, что вам не нужно добавлять Trace.WriteLine и Debug.WriteLine для регистрации в сборках отладки и выпуска. Использование TraceSources позволит вам использовать ETW в будущем, так как есть ETWTraceListener, доступный начиная с .NET (возможно, 3.5, конечно, на 4.0). НО эта конкретная функциональность ETW доступна только в Vista и более поздних версиях ОС.

Чтобы добавить способность к System.Diagnostics (в первую очередь, возможно, только при регистрации через TraceSource), посмотрите на Ukadc.Diagnostics. Ukadc.Diagnostics добавляет довольно классную возможность форматирования (подобно тому, что вы можете делать с log4net и NLog) в System.Diagnostics. Нет зависимости от кода (просто установите Ukadc.Diagnostics и добавьте некоторую конфигурацию в ваш app.config). Я должен сказать, что я думаю, что это действительно круто.

Если вы хотите внести свой небольшой вклад в TraceSources, см. here для интересной реализации оболочки TraceSource, которая по существу дает TraceSources возможность «наследовать» регистрацию конфигурации из «предков» TraceSources (например, как log4net и NLog loggers могут наследовать параметры ведения журнала).