Лучшие практики ведения журнала [закрыто]

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

рамки

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

  • такой как log4net
323
.net asp.net logging tracing

10 ответов

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

рамки

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

A: Система.Диагностика.TraceSource, встроенный в .NET 2.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q: если вы используете трассировку, вы используете трассировку.Соотношение.StartLogicalOperation?

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

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

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

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

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

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

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

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

при создании область может сначала установить ActivityId при необходимости, вызвать StartLogicalOperation, а затем войти TraceEventType.Начать сообщение. На Dispose он может зарегистрировать сообщение остановки, а затем вызвать StopLogicalOperation.

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

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

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

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

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

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

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

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

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

слушатель

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

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

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

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

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

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

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

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

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

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

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

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

трассировка активности (start, stop и т. д.) полезна здесь (в правой гранулярности).

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

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

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

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

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

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

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

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

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

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

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

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

A: для файлов, как правило, вы хотите прокатки файлов журнала с точки зрения управляемости (с системой.Диагностика просто использует VisualBasic.Лесозаготовительный.FileLogTraceListener).

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

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

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

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

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

просмотр

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

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

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

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

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

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

другие --

Если вы входите в База данных это может быть легко фильтровать и сортировать informatio (например, увеличить на определенный идентификатор активности. (С текстовыми файлами, вы можете использовать команду grep/PowerShell или похож на фильтр на partiular GUID, который вы хотите)

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

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

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

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

Q: если вы строите ASP.NET решение, вы также использовать ASP.NET мониторинг здоровья? Вы включаете выходные данные трассировки в события монитора работоспособности? А как же Трейс?классов AXD?

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

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

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

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

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

232

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

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

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

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

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

рамки

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

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

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

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

19

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

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

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

мы использование библиотеки ведения журнала Apache commons, обернутой вокруг Log4J.

надеюсь, что это помогает!

* Edit*

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

17

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

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

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

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

Я вижу некоторые преимущества в использовании трассировки, которая находится в .NET framework, но я не полностью продан, главным образом потому, что компоненты, с которыми я работаю, на самом деле не делают никаких вызовов трассировки. Единственное, что я часто использую, это 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 (поэтому, если отладка не включена, операторы отладки игнорируются), но когда я получу некоторое время, я буду обновлять его, чтобы выставить их, чтобы вы могли сделать проверки самостоятельно. Это предотвратит проведение оценок, когда они не должны, например:

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);

(сэкономить немного времени execusion)

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

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

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

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

9

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

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

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

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

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

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

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

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

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

8

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

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

6

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

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

5

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

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

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

Edit:

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

1

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

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

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

1