.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 сообщениями трассировки, хотя это простой способ получить важные события в приложении.