Регистрация лучших практик

Question

Регистрация лучших практик

339

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

Каркасы

Какие рамки вы используете?

log4net
System.Diagnostics.Trace
System.Diagnostics.TraceSource
Блок приложений журнала
Другое?

Если вы используете трассировку, используете ли вы Trace.Correlation.StartLogicalOperation?

Вы пишете этот код вручную или используете какую-то форму аспектно-ориентированного программирования? Хотите поделиться фрагментом кода?

Предоставляете ли вы какую-либо форму детализации по источникам трассировки? Например, WPF TraceSources позволяет вам настраивать их на разных уровнях:

System.Windows - настройки для всех WPF
System.Windows.Animation - переопределить специально для анимации.

Слушателей

Какие выходы журнала вы используете?

Текстовые файлы
XML файлы
Журнал событий
Другое?

При использовании файлов вы используете скользящие журналы или только один файл? Как сделать журналы доступными для людей?

Просмотр

Какие инструменты вы используете для просмотра журналов?

Блокнот
Tail
Просмотр событий
Центр управления Operations Manager/Microsoft Operations Manger
Средство просмотра трассировки WCF
Другое?

Если вы создаете решение ASP.NET, используете ли вы также мониторинг работоспособности ASP.NET? Включите вывод трассировки в событиях мониторинга работоспособности? Как насчет Trace.axd?

Как насчет пользовательских счетчиков производительности?

Paul Stovell 23 фев. 2009, в 01:20

Источник

3

Было бы полезно, если бы люди, закрывающие подобные вопросы с 300 ответами, могли предложить либо вики-формат, либо публикацию на programmers.stackexchange, либо Quora, если этот тип вопросов не приветствуется. Очевидно, что вопрос на самом деле очень конструктивный, он просто не соответствует критериям, которые хочет StackOverflow. programmers.stackexchange.com/questions/57064/… имеет 24 отзыва. Возможно, в StackOverflow чего-то не хватает?
Niall Connaughton 21 авг. 2013, в 05:55
0

Если этот вопрос нарушает формат вопросов и ответов, значит, что-то НЕПРАВИЛЬНО с форматом вопросов и ответов, а не с этим вопросом. Иногда решение о том, должен ли вопрос быть закрыт, должно зависеть от предоставленных ответов, некоторые открытые вопросы вызывают дебаты, но другие приглашают пользователей предоставить ценный контент, такой как этот!
Matt 04 окт. 2013, в 08:21
1

Этот вопрос - особенно самый лучший ответ - вероятно, послужил бы отличной основой для сообщения в блоге, если бы кто-то захотел использовать его как таковой ... Как объективный вопрос, он не совсем подходит - он явно структурирован как соломенный опрос - но Ниже приведена полезная информация, отсюда и замок.
Shog9♦ 10 окт. 2013, в 17:00

Показать ещё 1 комментарий

Теги:

asp.net

.net

logging

tracing

10 ответов

41

Мне нужно присоединиться к хору, рекомендующему log4net, в моем случае исходя из гибкости платформы (настольная .Net/Compact Framework, 32/64-разрядная).

Однако обертывание в API-интерфейсе private-label является основным анти-шаблоном. log4net.ILogger - это .Net-копия Commons Logging wrapper API, так что связь уже сведена к минимуму для вас, и поскольку она также является библиотекой Apache, которая обычно даже не вызывает беспокойства, потому что вы не отказываетесь от какого-либо контроля: если вы это сделаете, то переделайте ее.

Большинство библиотек оболочки дома, которые я видел, также совершают одно или несколько из-за ошибок:

Использование глобального однострочного регистратора (или, что то же самое, статическая точка входа), которая теряет точное разрешение рекомендуемого logger-per- class, чтобы не было другого усиления избирательности.
Невозможно открыть необязательный аргумент Exception, что приведет к нескольким проблемам:
- Это делает политику регистрации исключений еще более сложной для поддержания, поэтому ничего не делается последовательно с исключениями.
- Даже при согласованной политике форматирование исключения в строку исключает преждевременно. Я написал пользовательский декодер ILayout, который выполняет подробное развёртывание исключения, чтобы определить цепочку событий.
Невозможно открыть свойства IsLevelEnabled, что отбрасывает возможность пропуска кода форматирования при отключении областей или уровней ведения журнала.

Jeffrey Hantin 23 фев. 2009, в 03:11

1

Мне было поручено перестроить (ужасную) внутреннюю обертку вокруг log4j во что-то несколько менее ужасное (это все еще довольно плохо, но это результат того, что я ввел требования, выдвинутые мной для log4j). Я пытался устранить глобальную статическую точку входа, но был сбит. Я действительно не понимаю суть. В нашей настройке log4j настолько сильно расширен и изменен, что его просто используют как диспетчер событий; мы используем его только потому, что кто-то спросил: «Как мы можем использовать log4j для этого?» Либо используйте log4whither прямо, либо просто напишите свой собственный фреймворк. Средняя дорога болезненна.
Adam Jaskiewicz 03 июнь 2009, в 16:25
25

Я не согласен с вашей рекомендацией не заворачивать log4net. Свернув его с тонким API модели провайдера, пользователи ваших библиотек классов могут подключить свою любимую среду ведения журналов. Конечно, YMMV, но описывать его как «главный анти-паттерн» немного догматично. Кроме того, тот факт, что существуют библиотеки-обертки с «перечнем ошибок», не является хорошим аргументом против хорошо написанной обертки.
Joe 20 июнь 2009, в 10:28
1

Называть что-то анти-паттерном не означает, что это всегда на 100% плохая идея - просто это создает тенденцию загнать себя в угол, если вы не будете осторожны. Кроме того, ILog / LogManager сам по себе является хорошо написанной мини-библиотекой-оберткой в образе регистрации общего достояния, которая включена в сборку log4net, но нет никаких причин, по которой ее нельзя извлечь и превратить в надлежащую запись общего достояния для CLR.
Jeffrey Hantin 22 июнь 2009, в 20:10

Показать ещё 1 комментарий

19

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

Каркасы

Используйте фреймворк абзаца регистратора - например, slf4j (или сворачивайте свой собственный), чтобы вы отделили реализацию регистратора от вашего API. Я видел, как несколько фреймворков логгера приходят и уходят, и вам лучше быть в состоянии принять новый без особых хлопот.
Попробуйте найти фреймворк, поддерживающий различные форматы вывода.
Попробуйте найти фреймворк, который поддерживает плагины/настраиваемые фильтры.
Используйте фреймворк, который можно настроить внешними файлами, чтобы ваши клиенты/потребители могли легко настраивать выход журнала, чтобы он мог легко считываться коммерческими приложениями управления журналами.
Обязательно не переходите на борт на пользовательских уровнях ведения журнала, иначе вы не сможете переходить в разные рамки ведения журнала.

Выход регистратора

Старайтесь избегать журналов стиля XML/RSS для ведения журнала, которые могут столкнуться с катастрофическими сбоями. Это важно, потому что, если выключатель питания отключен без записи вашего регистратора закрывающего тега </xxx>, ваш журнал не работает.
Отправлять сообщения. В противном случае может быть очень сложно отслеживать поток вашей программы.
Если вам нужно интернационализировать свои журналы, вы можете захотеть, чтобы у разработчика был только вход на английский язык (или ваш язык выбора).
Иногда наличие возможности вставки операторов регистрации в SQL-запросы может быть спасателем в ситуациях отладки. Например:

    -- Invoking Class: com.foocorp.foopackage.FooClass:9021
    SELECT * FROM foo;

Требуется ведение журнала на уровне классов. Обычно вам не нужны статические экземпляры регистраторов - это не стоит микро-оптимизации.
Маркировка и категоризация журнальных исключений иногда полезна, потому что не все исключения созданы равными. Поэтому, зная подмножество важных исключений, полезно время, если у вас есть монитор журналов, который должен отправлять уведомления о критических состояниях.
Фильтры дублирования сохранят ваше зрение и жесткий диск. Вы действительно хотите видеть, что одно и то же выражение о регистрации повторялось 10 ^ 10000000 раз? Разве не лучше было бы получить сообщение вроде: This is my logging statement - Repeated 100 times

Также см. этот мой вопрос.

Elijah 23 фев. 2009, в 04:56

5

фильтры дублирования - отличная идея
Paul Stovell 23 фев. 2009, в 04:00
0

Раньше я соглашался с проблемой сломанного тега, но большинство хороших авторов XML все равно не используют полный XML (т. е. не имеют корневого элемента), поэтому они могут регистрироваться без загрузки XML DOM. в редких случаях возникает проблема с частично записанной записью, вы можете исправить ее вручную
Paul Stovell 23 фев. 2009, в 04:01
0

Я годами возвращался к ведению журналов XML. Теперь это кажется чрезмерным для меня. Если мне нужен RSS-канал о состоянии приложения, я думаю, что это лучше реализовать с помощью утилиты мониторинга журналов.
Elijah 23 фев. 2009, в 06:15
0

Я согласен на RSS. Я больше думаю об инструментах визуализации, которые позволят вам лучше понять запись. с текстовыми файлами вы обычно хотите сохранить запись в одну строку; но иногда вы хотите включить следы стека или сериализованные объекты. вот где XML-журнал (используемый WCF) пригодится
Paul Stovell 23 фев. 2009, в 08:58
0

+1 за упоминание инструментария SQL-запросов. Это действительно очень полезно для корреляции трассировки базы данных и трассировки приложения. Я делаю это вручную в моем DAL, но мне интересно, какая поддержка инструмента есть для этой техники?
Constantin 14 янв. 2011, в 09:13

Показать ещё 3 комментария

17

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

Мы начали с регистратора Singleton, который использовался каждым потоком в JVM, и установили уровень ведения журнала для всего процесса. Это привело к огромным журналам, если нам пришлось отлаживать даже очень специфическую часть системы, поэтому урок номер один - сегментировать ваш журнал.

Наше текущее воплощение регистратора позволяет использовать несколько экземпляров с одним значением по умолчанию. Мы можем создать любое количество дочерних регистраторов, которые имеют разные уровни ведения журнала, но наиболее полезной гранью этой архитектуры является возможность создавать регистраторы для отдельных пакетов и классов, просто изменяя свойства ведения журнала. Урок номер два - создать гибкую систему, которая позволяет переопределять ее поведение без изменения кода.

Мы используем библиотеку регистрации головоломок Apache, обернутую вокруг Log4J.

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

* Изменить *

Прочитав пост Джеффри Хэнтина ниже, я понял, что должен был заметить, какова наша внутренняя обертка журнала. Теперь он по существу является factory и строго используется для получения рабочего журнала с использованием файла правильных свойств (который по старым причинам не был перенесен в позицию по умолчанию). Поскольку теперь вы можете указать файл конфигурации ведения журнала в командной строке, я подозреваю, что он станет еще более скудным, и если вы начнете новое приложение, я определенно соглашусь с его утверждением, что вы даже не должны беспокоиться об обертывании регистратора.

Steve Moyer 23 фев. 2009, в 01:51

0

Спасибо за ответ. Вы создаете дочерние регистраторы вручную в коде (то есть, они жестко запрограммированы) или с помощью какой-то автоматической / неявной вещи?
Paul Stovell 23 фев. 2009, в 01:21
0

Нет ... если мы добавим конфигурацию регистрации в файлы logging.properties для пакета или класса, они будут зарегистрированы в соответствии с этой конфигурацией, но любой пакет или класс, не настроенный специально, будет зарегистрирован на уровнях по умолчанию.
Steve Moyer 23 фев. 2009, в 13:20

9

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

Мы выбрали его по следующим причинам:

Простая конфигурация/реконфигурация в различных средах
Хорошее количество готовых добавлений
Одна из CMS, которую мы используем, уже построила в
Хорошее количество уровней журналов и конфигураций вокруг них

Я бы сказал, это говорит с точки зрения развития ASP.NET

Я вижу некоторые достоинства в использовании Trace, который находится в платформе .NET, но я не полностью продаюсь на нем, главным образом потому, что компоненты, с которыми я работаю, на самом деле не выполняют никаких вызовов Trace. Единственное, что я часто использую, это System.Net.Mail из того, что я могу сказать.

Итак, у нас есть библиотека, которая обертывает log4net, и внутри нашего кода нам просто нужны такие вещи:

Logger.Instance.Warn("Something to warn about");
Logger.Instance.Fatal("Something went bad!", new Exception());

try {
  var i = int.Parse("Hello World");
} catch(FormatException, ex) {
  Logger.Instance.Error(ex);
}

В рамках методов мы проверяем, включен ли уровень ведения журнала, поэтому у вас нет избыточных вызовов для API log4net (поэтому, если Debug не включен, операторы отладки игнорируются), но когда я получите некоторое время, я буду обновлять его, чтобы разоблачить их, чтобы вы сами могли выполнять проверки. Это предотвратит проведение оценок, если они не должны, например:

Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

Это станет следующим:

if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

(Сохраните немного времени выполнения)

По умолчанию мы регистрируемся в двух местах:

Файловая система веб-сайта (в незашифрованном расширении файла)
Отправка электронной почты для ошибок и фатальных

Файлы выполняются как катящиеся каждый день или 10 мб (IIRC). Мы не используем EventLog, так как это может потребовать более высокой безопасности, чем мы часто хотим предоставить сайт.

Я нахожу, что "Блокнот" отлично работает для чтения журналов.

Aaron Powell 23 фев. 2009, в 03:15

0

Каркасы журналирования - один из немногих случаев, когда синглтон не является злоупотреблением.
mmcdole 23 фев. 2009, в 02:01
0

Это может быть, если вы хотите предоставить контекст вокруг вашего регистратора. Но это помогает бороться с параллелизмом
Aaron Powell 23 фев. 2009, в 02:19
7

Я бы определенно вырвал синглтон. Вы, конечно, можете иметь один экземпляр, который будет передан (предпочтительно в контейнере IOC / DI). Я также попытался бы переместить вход в перехватчик ....
yfeldblum 23 фев. 2009, в 03:31
2

Не фанат ни одного экземпляра. Я предпочитаю присваивать каждому классу уникальное имя для ведения журналов, поэтому переключение регистрации вверх или вниз для каждого модуля является простым делом.
Jeffrey Hantin 25 окт. 2010, в 18:40

Показать ещё 2 комментария

8

Какие рамки вы используете?

Мы используем сочетание блока приложений ведения журнала и настраиваемый помощник ведения журнала, который работает с битами структуры .Net. LAB сконфигурирован для вывода довольно обширных файлов журналов, включающих отдельные файлы трассировки для ввода/вывода метода службы и конкретные файлы ошибок для неожиданных проблем. Конфигурация включает дату/время, поток, pId и т.д. Для поддержки отладки, а также полную информацию о деталях и стеке (в случае непредвиденного исключения).

Пользовательский помощник ведения журнала использует Trace.Correlation и особенно удобен в контексте ведения журнала в WF. Например, у нас есть машина состояний, которая вызывает серию последовательных рабочих процессов. При каждой из этих операций invoke мы записываем начало (используя StartLogicalOperation), а затем в конце мы останавливаем логическую операцию с помощью обработчика события gereric return.

Это оказалось полезным несколько раз при попытке отладить ошибки в сложных бизнес-последовательностях, поскольку это позволяет нам быстрее определять вещи, такие как If/Else, и т.д. быстрее на основе последовательности выполнения действий.

Какие выходы журнала вы используете?

Мы используем текстовые файлы и XML файлы. Текстовые файлы настраиваются через блок приложения, но у нас есть результаты XML также из нашей службы WF. Это позволяет нам фиксировать события времени выполнения (сохранение и т.д.), А также исключения общего типа бизнеса. Текстовые файлы - это скользящие журналы, которые свертываются днем и размером (я считаю, что общий размер 1 МБ является точкой опроса).

Какие инструменты вы используете для просмотра журналов?

Мы используем Notepad и WCF Service Trace Viewer в зависимости от группы вывода, на которую мы смотрим. WCF Service Trace Viewer действительно очень удобен, если вы правильно настроили выход и можете значительно упростить чтение вывода. Тем не менее, если я знаю грубую информацию о том, где ошибка, так или иначе, просто хорошо читается хорошо аннотированный текстовый файл.

Журналы отправляются в один каталог, который затем разбивается на субдиры на основе исходной службы. Корневой каталог открывается через веб-сайт, доступ к которому контролируется группой пользователей поддержки. Это позволяет нам просматривать журналы производства без необходимости вводить запросы и проходить длительные процессы красной ленты для производственных данных.

Steve Godbold 23 фев. 2009, в 04:36

6

В качестве авторов инструмента мы, конечно, используем SmartInspect для ведения журналов и трассировки приложений .NET. Обычно мы используем протокол named pipe для ведения журнала в реальном времени и (зашифрованный) двоичный файл журнала для журналов конечных пользователей. Мы используем SmartInspect Console в качестве средства просмотра и мониторинга.

На самом деле существует довольно много фреймворков регистрации и инструментов для .NET. Здесь представлен обзор и сравнение различных инструментов DotNetLogging.com.

Dennis G. 23 фев. 2009, в 10:49

5

В ответах есть много замечательных рекомендаций.

Общей рекомендацией является рассмотрение того, кто будет читать журнал. В моем случае это будет администратор на клиентском сайте. Поэтому я регистрирую сообщения, которые дают им то, над чем они могут действовать. Например, "Не удалось инициализировать приложение. Обычно это вызвано......"

Matthew Sposato 24 янв. 2011, в 15:05

1

Что касается аспектно-ориентированного ведения журнала, я был рекомендован PostSharp по другому вопросу SO -

Аспектно-ориентированное ведение журнала с помощью Unity\T4\anything else

Ссылка, содержащаяся в ответе, стоит посетить, если вы оцениваете рамки ведения журнала.

Unmesh Kondolikar 30 сен. 2010, в 15:56

1

Мы используем log4net в наших веб-приложениях.

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

Он также позволяет настроить таргетинг определенных классов или атрибутов для входа в систему. Это очень удобно, когда у вас есть идея, где происходит ошибка. Классическим примером является NHibernate, где вы хотите увидеть только SQL, идущий в базу данных.

Edit:

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

Jeffrey Cameron 23 фев. 2009, в 04:05

0

Можете ли вы предоставить более подробную информацию о том, как вы используете его? Вы входите в файл или журнал событий? Это скользящий файл журнала? Что вы делаете, чтобы защитить его или сделать резервную копию? Я заинтересован в реальном использовании.
Paul Stovell 23 фев. 2009, в 03:40
0

Конечно, извините. Будет редактировать
Jeffrey Cameron 23 фев. 2009, в 14:06

Ещё вопросы

Было бы полезно, если бы люди, закрывающие подобные вопросы с 300 ответами, могли предложить либо вики-формат, либо публикацию на programmers.stackexchange, либо Quora, если этот тип вопросов не приветствуется. Очевидно, что вопрос на самом деле очень конструктивный, он просто не соответствует критериям, которые хочет StackOverflow. programmers.stackexchange.com/questions/57064/… имеет 24 отзыва. Возможно, в StackOverflow чего-то не хватает?
Если этот вопрос нарушает формат вопросов и ответов, значит, что-то НЕПРАВИЛЬНО с форматом вопросов и ответов, а не с этим вопросом. Иногда решение о том, должен ли вопрос быть закрыт, должно зависеть от предоставленных ответов, некоторые открытые вопросы вызывают дебаты, но другие приглашают пользователей предоставить ценный контент, такой как этот!
Этот вопрос - особенно самый лучший ответ - вероятно, послужил бы отличной основой для сообщения в блоге, если бы кто-то захотел использовать его как таковой ... Как объективный вопрос, он не совсем подходит - он явно структурирован как соломенный опрос - но Ниже приведена полезная информация, отсюда и замок.
Мне было поручено перестроить (ужасную) внутреннюю обертку вокруг log4j во что-то несколько менее ужасное (это все еще довольно плохо, но это результат того, что я ввел требования, выдвинутые мной для log4j). Я пытался устранить глобальную статическую точку входа, но был сбит. Я действительно не понимаю суть. В нашей настройке log4j настолько сильно расширен и изменен, что его просто используют как диспетчер событий; мы используем его только потому, что кто-то спросил: «Как мы можем использовать log4j для этого?» Либо используйте log4whither прямо, либо просто напишите свой собственный фреймворк. Средняя дорога болезненна.
Я не согласен с вашей рекомендацией не заворачивать log4net. Свернув его с тонким API модели провайдера, пользователи ваших библиотек классов могут подключить свою любимую среду ведения журналов. Конечно, YMMV, но описывать его как «главный анти-паттерн» немного догматично. Кроме того, тот факт, что существуют библиотеки-обертки с «перечнем ошибок», не является хорошим аргументом против хорошо написанной обертки.
Называть что-то анти-паттерном не означает, что это всегда на 100% плохая идея - просто это создает тенденцию загнать себя в угол, если вы не будете осторожны. Кроме того, ILog / LogManager сам по себе является хорошо написанной мини-библиотекой-оберткой в образе регистрации общего достояния, которая включена в сборку log4net, но нет никаких причин, по которой ее нельзя извлечь и превратить в надлежащую запись общего достояния для CLR.
фильтры дублирования - отличная идея
Раньше я соглашался с проблемой сломанного тега, но большинство хороших авторов XML все равно не используют полный XML (т. е. не имеют корневого элемента), поэтому они могут регистрироваться без загрузки XML DOM. в редких случаях возникает проблема с частично записанной записью, вы можете исправить ее вручную
Я годами возвращался к ведению журналов XML. Теперь это кажется чрезмерным для меня. Если мне нужен RSS-канал о состоянии приложения, я думаю, что это лучше реализовать с помощью утилиты мониторинга журналов.
Я согласен на RSS. Я больше думаю об инструментах визуализации, которые позволят вам лучше понять запись. с текстовыми файлами вы обычно хотите сохранить запись в одну строку; но иногда вы хотите включить следы стека или сериализованные объекты. вот где XML-журнал (используемый WCF) пригодится
+1 за упоминание инструментария SQL-запросов. Это действительно очень полезно для корреляции трассировки базы данных и трассировки приложения. Я делаю это вручную в моем DAL, но мне интересно, какая поддержка инструмента есть для этой техники?
Спасибо за ответ. Вы создаете дочерние регистраторы вручную в коде (то есть, они жестко запрограммированы) или с помощью какой-то автоматической / неявной вещи?
Нет ... если мы добавим конфигурацию регистрации в файлы logging.properties для пакета или класса, они будут зарегистрированы в соответствии с этой конфигурацией, но любой пакет или класс, не настроенный специально, будет зарегистрирован на уровнях по умолчанию.
Каркасы журналирования - один из немногих случаев, когда синглтон не является злоупотреблением.
Это может быть, если вы хотите предоставить контекст вокруг вашего регистратора. Но это помогает бороться с параллелизмом
Я бы определенно вырвал синглтон. Вы, конечно, можете иметь один экземпляр, который будет передан (предпочтительно в контейнере IOC / DI). Я также попытался бы переместить вход в перехватчик ....
Не фанат ни одного экземпляра. Я предпочитаю присваивать каждому классу уникальное имя для ведения журналов, поэтому переключение регистрации вверх или вниз для каждого модуля является простым делом.
Можете ли вы предоставить более подробную информацию о том, как вы используете его? Вы входите в файл или журнал событий? Это скользящий файл журнала? Что вы делаете, чтобы защитить его или сделать резервную копию? Я заинтересован в реальном использовании.
Конечно, извините. Будет редактировать

Sly Gryphon · Accepted Answer · 2009-06-02T15-16-00.000Z

Обновление:. Для расширений System.Diagnostics, предоставляющих некоторые из отсутствующих слушателей, которые могут вам понадобиться, см. Essential.Diagnostics в CodePlex (http://essentialdiagnostics.codeplex.com/)

Каркасы

В: Какие рамки вы используете?

A: System.Diagnostics.TraceSource, встроенный в .NET 2.0.

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

Есть некоторые области, где полезны дополнительные функциональные возможности, или иногда существует функциональность, но она плохо документирована, однако это не означает, что вся структура ведения журнала (которая должна быть расширяемой) должна быть выброшена и полностью заменена как некоторые популярные альтернативы (NLog, log4net, Common.Logging и даже EntLib Logging).

Вместо того, чтобы изменять способ добавления операторов регистрации в приложение и повторно изобретать колесо, просто расширив рамки System.Diagnostics в тех немногих местах, в которых вы нуждаетесь.

Мне кажется, что другие структуры, даже EntLib, просто страдают от Inv Invented Here Syndrome, и я думаю, что они потратили впустую время, повторно изобретая основы, которые уже отлично работают в System.Diagnostics(например, как вы записываете журнал заявления), а не заполнять несколько пробелов, которые существуют. Короче говоря, не используйте их - они не нужны.

Возможности, которые вы, возможно, не знали:

Использование перегрузок TraceEvent, которые принимают строку формата, и args могут помочь производительности, поскольку параметры сохраняются в виде отдельных ссылок до тех пор, пока Filter.ShouldTrace() не удастся. Это означает, что дорогие вызовы ToString() по значениям параметров до тех пор, пока система не подтвердит, что сообщение действительно будет зарегистрировано.
Trace.CorrelationManager позволяет вам сопоставлять записи журнала о той же логической операции (см. ниже).
VisualBasic.Logging.FileLogTraceListener хорош для записи в файлы журнала и поддержки вращения файлов. Хотя в пространстве имен VisualBasic его можно так же легко использовать в проекте С# (или другого языка), просто включив DLL.
При использовании EventLogTraceListener, если вы вызываете TraceEvent с несколькими аргументами и с пустой или нулевой строкой формата, тогда аргументы передаются непосредственно в EventLog.WriteEntry(), если вы используете локализованные ресурсы сообщений.
Средство просмотра службы трассировки (из WCF) полезно для просмотра графиков коррелированных файлов журнала действий (даже если вы не используете WCF). Это может действительно помочь отладить сложные проблемы, когда задействовано несколько потоков/действий.
Избегайте накладных расходов, освобождая всех слушателей (или удаляя по умолчанию); в противном случае По умолчанию будет передано все в систему трассировки (и на них наложены все служебные данные ToString()).

Области, которые вы, возможно, захотите посмотреть на расширение (если необходимо):

Слушатель трассировки базы данных
Цветной прослушиватель трассировки консоли
Слушатели MSMQ/Email/WMI (при необходимости)
Реализация FileSystemWatcher для вызова Trace.Refresh для динамических изменений конфигурации

Другие рекомендации:

Используйте структурированные идентификаторы событий и сохраняйте список ссылок (например, документируйте их в перечислении).

Наличие уникального идентификатора события для каждого (значимого) события в вашей системе очень полезно для корреляции и поиска конкретных проблем. Легко отследить назад к конкретному коду, который регистрирует/использует идентификаторы событий, и может упростить предоставление рекомендаций для распространенных ошибок, например. ошибка 5178 означает, что ваша строка подключения к базе данных неверна и т.д.

Идентификатор события должен следовать какой-то структуре (аналогичной теории кодов ответа, используемой в электронной почте и HTTP), что позволяет вам относиться к ним по категориям, не зная конкретных кодов.

например. Первая цифра может содержать подробный общий класс: 1xxx может использоваться для операций "Начало", 2xxx для нормального поведения, 3xxx для отслеживания активности, 4xxx для предупреждений, 5xxx для ошибок, 8xxx для операций "Стоп", 9xxx для фатальных ошибок и т.д..

Вторая цифра может детализировать область, например. 21xx для информации о базе данных (41xx для предупреждений о базе данных, 51xx для ошибок базы данных), 22xx для режима расчета (42xx для предупреждений о расчетах и т.д.), 23xx для другого модуля и т.д.

Назначенный, структурированный идентификатор события также позволяет использовать их в фильтрах.

В: Если вы используете трассировку, вы используете Trace.Correlation.StartLogicalOperation?

A: Trace.CorrelationManager очень полезен для корреляции операторов журналов в любой разнотипной среде (что в наши дни практически что-то похожее).

Вам нужно, по крайней мере, установить ActivityId один раз для каждой логической операции, чтобы коррелировать.

Пуск/Стоп и LogicalOperationStack можно затем использовать для простого контекста на основе стека. Для более сложных контекстов (например, асинхронных операций) использование TraceTransfer для нового ActivityId (перед его изменением) позволяет коррелировать.

Средство просмотра трассировки службы может быть полезно для просмотра графиков активности (даже если вы не используете WCF).

В: Вы пишете этот код вручную или используете какую-то форму аспектно-ориентированного программирования? Хотите поделиться фрагментом кода?

A: Вы можете создать класс области видимости, например. LogicalOperationScope, который (а) устанавливает контекст при создании и (б) сбрасывает контекст при его размещении.

Это позволяет вам написать код, например, следующий, чтобы автоматически обернуть операции:

  using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
  {
    // .. do work here
  }

При создании области можно сначала установить ActivityId, если необходимо, вызвать StartLogicalOperation и затем записать сообщение TraceEventType.Start. В Dispose он может записать сообщение Stop, а затем вызвать StopLogicalOperation.

В: Предоставляете ли вы какую-либо форму детализации по источникам трассировки? Например, WPF TraceSources позволяет вам настраивать их на разных уровнях.

A: Да, многостраничные источники трассировки полезны/важны, поскольку системы становятся больше.

Несмотря на то, что вы, вероятно, хотите постоянно регистрировать все предупреждения и выше или все сообщения Information и выше, для любой системы с разумным размером объем трассировки активности (запуск, остановка и т.д.) и подробный журнал просто становятся слишком большими.

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

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

Количество источников трассировки, которые вам нужны, зависит от вашего приложения, например. вам может понадобиться один источник трассировки на сборку или на основную часть вашего приложения.

Если вам требуется еще более точная настройка, добавьте отдельные логические переключатели, чтобы включить/выключить специальную трассировку большого объема, например. необработанные сообщения. (Или можно использовать отдельный источник трассировки, аналогичный WCF/WPF).

Вы также можете рассмотреть отдельные источники трассировки для Activity Tracing vs general (other) logging, так как это может упростить настройку фильтров точно так, как вы хотите.

Обратите внимание, что сообщения все еще могут быть скоррелированы с помощью ActivityId, даже если используются разные источники, поэтому используйте столько, сколько вам нужно.

Слушатели

В: Какие выходы журнала вы используете?

Это может зависеть от того, какой тип приложения вы пишете, и какие вещи регистрируются. Обычно разные вещи идут в разных местах (т.е. Несколько выходов).

Я обычно классифицирую выходы на три группы:

(1) События - Журнал событий Windows (и файлы трассировки)

например. Если вы пишете сервер/службу, то лучше всего использовать Windows-журнал событий (у вас нет пользовательского интерфейса для отчета).

В этом случае все информационные события Fatal, Error, Warning и (service-level) должны перейти в журнал событий Windows. Информационный уровень должен быть зарезервирован для этих типов событий высокого уровня, те, которые вы хотите включить в журнал событий, например. "Сервис запущен", "Сервис остановлен", "Подключен к Xyz" и, возможно, даже "Расписано инициировано", "Пользователь зарегистрирован" и т.д.

В некоторых случаях вы можете захотеть записать в журнал событий встроенную часть вашего приложения, а не через систему трассировки (т.е. записать записи журнала событий напрямую). Это означает, что он не может быть случайно отключен. (Обратите внимание, что вы также хотите отметить одно и то же событие в вашей системе слежения, чтобы вы могли коррелировать).

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

События могут также иметь связанные счетчики производительности (например, количество ошибок/сек), и может быть важно координировать любую прямую запись в журнал событий, счетчики производительности, запись в систему слежения и отчетность пользователю они происходят одновременно.

то есть. Если пользователь видит сообщение об ошибке в определенное время, вы должны найти одно и то же сообщение об ошибке в Журнале событий Windows, а затем одно и то же событие с той же меткой времени в журнале трассировки (вместе с другими данными трассировки).

(2) Действия - Файлы журнала приложений или таблица базы данных (и файлы трассировки)

Это регулярное действие, которое делает система, например. веб-страницы, торговля на фондовом рынке, порядок, выполненный расчет и т.д.

Трассировка активности (запуск, остановка и т.д.) полезна здесь (с правильной граничностью).

Кроме того, очень часто используется конкретный журнал приложений (иногда называемый журналом аудита). Обычно это таблица базы данных или файл журнала приложения и содержит структурированные данные (т.е. Набор полей).

Здесь может быть немного размыто в зависимости от вашего приложения. Хорошим примером может быть веб-сервер, который записывает каждый запрос в веб-журнал; аналогичные примеры могут представлять собой систему обмена сообщениями или систему вычислений, в которой каждая операция регистрируется вместе с подробными данными приложения.

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

Также как и журналы пользовательских приложений, действия также часто имеют связанные счетчики производительности, например. количество транзакций в секунду.

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

(3) Отладка трассировки - текстовый файл, а может быть, XML или база данных.

Это информация на уровне Verbose и ниже (например, пользовательские логические ключи для включения/выключения исходных дампов данных). Это обеспечивает кишки или детали того, что система делает на уровне под-активности.

Это уровень, который вы хотите включить/выключить для отдельных разделов приложения (отсюда и несколько источников). Вы не хотите, чтобы этот материал загромождал журнал событий Windows. Иногда используется база данных, но, скорее всего, это скопированные файлы журналов, которые очищаются через определенное время.

Большая разница между этой информацией и файлом журнала приложений заключается в том, что она неструктурирована. В то время как в журнале приложений могут быть поля для "To", "From", "Amount" и т.д., "Verbose" трассировки отладки могут быть любыми, что вводит программист, например. "проверка значений X = {значение}, Y = false" или случайных комментариев/маркеров, таких как "Done it, try again".

Одной из важных практик является то, что все, что вы помещаете в файлы журнала приложений или журнал событий Windows, также регистрируется в системе трассировки с теми же данными (например, timestamp). Это позволяет вам затем сопоставлять различные журналы при расследовании.

Если вы планируете использовать определенный просмотрщик журналов, потому что у вас сложная корреляция, например. Service Trace Viewer, тогда вам нужно использовать соответствующий формат, то есть XML. В противном случае простой текстовый файл обычно достаточно хорош - на более низких уровнях информация в значительной степени неструктурирована, поэтому вы можете найти дампы массивов, дампов стеков и т.д. Если вы можете соотнестись с более структурированными журналами на более высоких уровнях, все должно быть все в порядке.

В: Если вы используете файлы, вы используете скользящие журналы или только один файл? Как сделать журналы доступными для людей?

A: Для файлов обычно требуется скопировать файлы журналов с точки зрения управляемости (с помощью System.Diagnostics просто используйте VisualBasic.Logging.FileLogTraceListener).

Доступность снова зависит от системы. Если вы говорите только о файлах, то для сервера/службы, при необходимости можно загружать файлы для скачивания. (Журнал событий Windows или журналы приложений баз данных будут иметь свои собственные механизмы доступа).

Если у вас нет простого доступа к файловой системе, отладка трассировки в базе данных может быть проще. [Т.е. реализовать базу данных TraceListener].

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

Если, однако, он разбился или столкнулся с проблемой, файл не был удален. Либо если он поймает ошибку, либо при следующем запуске заметит файл, а затем он может принять меры, например. сжать его (например, 7zip) и отправить по электронной почте или иным образом сделать доступным.

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

Просмотр

В: Какие инструменты вы используете для просмотра журналов?

A: Если у вас несколько журналов по разным причинам, вы будете использовать несколько зрителей.

Notepad/vi/Notepad ++ или любой другой текстовый редактор является базовым для обычных текстовых журналов.

Если у вас сложные операции, например. действия с передачами, то вы, очевидно, будете использовать специализированный инструмент, такой как Service Trace Viewer. (Но если вам это не нужно, тогда текстовый редактор проще).

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

Как правило, журнал событий Windows также делает эти важные события доступными для таких инструментов мониторинга, как MOM или OpenView.

Другие -

Если вы заходите в базу данных, можно легко фильтровать и сортировать информацию (например, масштабировать определенный идентификатор активности. (С текстовыми файлами вы можете использовать Grep/PowerShell или аналогично фильтру по желаемому GUID-GUID)

MS Excel (или другая программа для работы с электронными таблицами). Это может быть полезно для анализа структурированной или полуструктурированной информации, если вы можете импортировать ее с помощью правильных разделителей, чтобы разные значения попадали в разные столбцы.

При запуске службы в debug/test я обычно размещаю ее в консольном приложении для простоты. Я нашел полезный цветной консольный журнал (например, красный для ошибок, желтый для предупреждений и т.д.). Вам необходимо реализовать пользовательский прослушиватель трассировки.

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

Меня действительно раздражает, что несколько фреймворков (log4net, EntLib и т.д.) потеряли время, повторно изобретая колесо, и повторно выполнили базовое ведение журнала, фильтрацию и протоколирование в текстовые файлы, журнал событий Windows и файлы XML, каждый по-своему (в каждом из журнальных операторов разные); каждый из них затем реализовал собственную версию, например, регистратора базы данных, когда большая часть из них уже существовала и все, что было необходимо, было еще несколькими прослушивателями трассировки для System.Diagnostics. Поговорите о большой трате дублирующих усилий.

В: Если вы строите решение ASP.NET, используете ли вы также мониторинг работоспособности ASP.NET? Включите вывод трассировки в событиях мониторинга работоспособности? Как насчет Trace.axd?

Эти вещи могут быть включены/выключены по мере необходимости. Я нахожу Trace.axd весьма полезной для отладки, как сервер реагирует на определенные вещи, но он обычно не полезен в сильно используемой среде или для долговременной трассировки.

В: Как насчет пользовательских счетчиков производительности?

Для профессионального приложения, особенно сервера/службы, я ожидаю, что он будет полностью оснащен обеими счетчиками Performance Monitor и протоколируется в журнале событий Windows. Это стандартные инструменты в Windows и должны использоваться.

Необходимо включить инсталляторы для счетчиков производительности и журналов событий, которые вы используете; они должны быть созданы во время установки (при установке в качестве администратора). Когда ваше приложение работает нормально, ему не нужно иметь права администратора (и поэтому не сможет создавать отсутствующие журналы).

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

К вашему сведению: я столкнулся с проблемой, из-за которой происходит сбой трассировки файла Microsoft. Если у вас есть несколько процессов (или потоков), пишущих в один и тот же файл, и они сталкиваются, вы получаете ошибку блокировки монопольного доступа к файловой системе в файле журнала.
@ Джей, это ошибка с слушателем трассировки (вы можете написать свой собственный), а не с инфраструктурой трассировки
Инфраструктура System.Diagnostics является поточно-ориентированной; поведение по умолчанию для блокировки платформы, однако вы можете переопределить TraceListener.IsThreadSafe, если вы предоставляете свою собственную блокировку. См. Msdn.microsoft.com/en-us/library/… . Для нескольких процессов вы обычно пишете в отдельные файлы, но учтите, что средство просмотра трассировки служб может загружать несколько файлов трассировки (например, с нескольких компьютеров) и сопоставлять их через ActivityId.
Может быть, вы можете предложить, как использовать TraceEvent () для регистрации исключений?
Не является ли одним из главных недостатков System.Diagnostics.Trace то, что он украшен [Conditional("TRACE")] что делает его непригодным для использования в производственных средах, где у вас редко есть код, скомпилированный с флагом TRACE ?
@Dmitriy Зарегистрировать исключение легко: source.TraceEvent (TraceEventType.Error, 5000, «Возникло исключение: {0}», исключение); (это получит полную трассировку стека и т. д., не используйте исключение. Сообщение, так как обычно у него недостаточно информации).
@asbjornu Конфигурация сборки релиза по умолчанию в Visual Studio имеет TRACE (это отключение DEBUG для сборок релиза); однако, если вы делаете сборку из командной строки, ее нужно включить.