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

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

Каркасы

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

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

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

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

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

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

Слушатели

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

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

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

Просмотр

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

  • Блокнот
  • Хвост
  • Просмотрщик событий
  • Системный центр Operations Manager / Microsoft Operations Manger
  • WCF Service Trace Viewer
  • Другой?

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

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

Источник

10 ответов

Решение

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

Каркасы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слушатели

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

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

Я обычно делю результаты на три группы:

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

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

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

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

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

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

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

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

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

Отслеживание активности (начало, остановка и т. Д.) Полезно здесь (при правильной детализации).

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

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

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

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

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

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

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

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

Большая разница между этой информацией и файлом журнала приложений заключается в том, что он неструктурирован. Хотя в журнале приложений могут быть поля для "Кому", "От", "Сумма" и т. Д., "Подробные трассировки отладки" могут представлять собой то, что вносит программист, например "проверка значений X={значение}, Y=false" или случайные комментарии / маркеры, например " Сделано, пытаясь снова ".

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

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

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

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

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

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

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

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

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

Просмотр

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

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

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

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

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

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

Другие -

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

Каркасы

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

Logger Output

  • Старайтесь избегать журналов в стиле XML/RSS для ведения журналов, которые могут привести к катастрофическим сбоям. Это важно, потому что, если выключатель питания отключен без вашего регистратора, пишущего закрытие </xxx> тег, ваш журнал не работает.
  • Журнал темы. В противном случае может быть очень трудно отследить поток вашей программы.
  • Если вам нужно интернационализировать ваши журналы, вы можете захотеть, чтобы разработчик входил только на английском языке (или на ваш язык по вашему выбору).
  • Иногда возможность вставлять операторы регистрации в запросы SQL может быть спасением в ситуациях отладки. Такие как:
 - Класс вызова: com.foocorp.foopackage.FooClass:9021
    ВЫБРАТЬ * ОТ foo;
  • Вы хотите ведение журнала на уровне класса. Обычно вам также не нужны статические экземпляры регистраторов - это не стоит микрооптимизации.
  • Пометка и классификация зарегистрированных исключений иногда полезна, потому что не все исключения созданы равными. Таким образом, знание подмножества важных исключений полезно, если у вас есть монитор журналов, который должен отправлять уведомления о критических состояниях.
  • Фильтры дублирования сохранят ваше зрение и жесткий диск. Вы действительно хотите, чтобы один и тот же оператор записи повторялся 10^10000000 раз? Разве не было бы лучше просто получить сообщение как:This is my logging statement - Repeated 100 times

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

Источник

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

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

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

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

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

* Редактировать *

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

Источник

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

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

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

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

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

(Сэкономьте немного времени на исполнение)

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

Источник

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

На самом деле существует довольно много каркасов и инструментов для ведения журнала.NET. На http://www.dotnetlogging.com/ есть обзор и сравнение различных инструментов.

Источник

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

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

Источник

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

Аспектно-ориентированное ведение журнала с Unity\T4\ что-нибудь еще

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

Источник

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

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

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

Редактировать:

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

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