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

Мы изначально не использовали трассировку протоколирования или отладки, но, потратив несколько недель на отслеживание некоторого искажения данных, мы решили разместить требуемые Debug.Write и Trace для производства и 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?

Ответ 1

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

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

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

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

Если вы еще не видели инструментарий Perf и средство просмотра XPerf, то вы готовы к удовольствию!: D

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

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

Ответ 2

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

Я думаю, вам следует использовать 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, см. здесь для интересной реализации оболочки TraceSource, которая по существу дает TraceSources возможность "наследовать" регистрацию конфигурации из "предков" TraceSources (например, как log4net и NLog loggers могут наследовать параметры ведения журнала).

Ответ 3

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

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

Ответ 4

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