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

Источник

4 ответа

Решение

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

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

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

  1. Диагностика: использование трассировки ETW в.NET 3.5 (EventProviderTraceListener)
  2. Управление текстом ссылки.NET Framework Logging
  3. Двухминутная тренировка: Введение в XPerf

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

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

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

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

Источник

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

Я думаю, вам следует рассмотреть возможность использования 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 в будущем, так как начиная с.NET доступен ETWTraceListener (возможно, 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. может наследовать настройки логирования).

Источник

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

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

Источник

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

Источник
Другие вопросы по тегам