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