Лучшие практики .net Diagnostics?
Мы первоначально не использовали трассировки входа или отладки, но после пребывания в течение нескольких недель для трассировки вниз некоторого повреждения данных, мы решили поместить требуемую Отладку. Запишите и Трассировка для производства и Отладки. Утверждать
Поэтому теперь вопрос - то, Что является лучшей практикой для использования входа трассировки и отладки. Я просто ищу некоторую универсальную вещь.
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. Диагностика по другим альтернативам как log4net.
Есть ли любая вещь, еще полезная в Системе. Диагностика?
3 ответа
Вы должны планировать поднимать события трассировки ETW по всему вашему приложению - не только для предупреждения слушателей о проблемах, но и для обеспечения видимости поведения и даже производительности ваших приложений и компонентов.
ETW - это (безумно) высокопроизводительный и (поразительно) малозатратный способ сбора событий, которые можно собирать и анализировать - даже в производственных средах. Это инфраструктура протоколирования и трассировки, используемая в Windows, SQL и т.д.
Три полезные ссылки для вас:
- Диагностика: Использование трассировки ETW в .NET 3.5 (EventProviderTraceListener)
- Контролирующий текст ссылки .NET Framework Logging
- Two Minute Drill: Introduction to XPerf
Прочитайте все три ссылки по порядку, а затем перечитайте еще раз - последующая информация будет очень полезной, но ее будет труднее понять, если вы сначала не усвоите основы ;) Игнорируйте инструкции по использованию logman для запуска и остановки коллекций трасс; вместо этого используйте XPerf.
Если вы еще не видели инструментарий Perf и XPerf viewer, то вас ждет удовольствие! :D
Я настоятельно рекомендую вам рассмотреть возможность создания событий запуска и остановки в начале и конце всех наиболее важных функций вашего приложения, чтобы вы могли наложить эти события на другую телеметрию, чтобы вы могли увидеть, например, влияние функций вашего приложения на диск, сеть, память, CPU и т.д.
Надеюсь, это поможет.
Вы используете его нормально, за исключением Assert с первым аргументом, жестко заданным на true . Вам, вероятно, следует добавить туда какое-то условие, и сообщение (второй аргумент) будет напечатано только в том случае, если условие ложно. Таким образом, в вашем примере кода он никогда не будет отображаться. В некоторых случаях WriteLineIf может пригодиться, если вы не хотите заключать операторы отладки в условные блоки.
См. Справочник по классу отладки , в нем есть довольно много полезных методов и свойств, которые помогут вам вести журнал.
System.Diagnostics также содержит EventLog.WriteEntry, но вы можете или не хотите заполнять EventLog сообщениями трассировки, хотя это простой способ регистрации основных событий приложения.