Оптимизация ведения журнала

Ответ 1

Обновление:. Для расширений 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 автоматически создаст отсутствующий журнал при первом его записи; если вы разрабатываете как не-админ, вы поймете это раньше и избегаете неприятного сюрприза, когда клиент устанавливает вашу систему, а затем не может использовать ее, потому что они не работают как администратор.

Ответ 2

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

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

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

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

Ответ 3

Я не часто развивается в 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

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

Ответ 4

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

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

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

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

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

* Изменить *

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

Ответ 5

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

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

Ответ 6

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

Мы используем сочетание блока приложений ведения журнала и настраиваемый помощник ведения журнала, который работает с битами структуры .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 действительно очень удобен, если вы правильно настроили выход и можете значительно упростить чтение вывода. Тем не менее, если я знаю грубую информацию о том, где ошибка, так или иначе, просто хорошо читается хорошо аннотированный текстовый файл.

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Edit:

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

Ответ 10

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

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

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