Ведение журнала и трассировка .NET

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

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

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

Основные различия в API ведения журнала

Структурированное ведение журнала

API ведения журнала можно структурировать или неструктурировать:

• Неструктурированные записи журнала содержат текстовое содержимое свободной формы, которое предназначено для просмотра людьми.
• Структурировано: записи журнала имеют четко определенную схему и могут быть закодированы в разных двоичных и текстовых форматах. Эти журналы предназначены для машинного перевода и запроса, чтобы и люди, и автоматизированные системы могли работать с ними легко.

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

Настройка

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

Приемники

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

API ведения журнала .NET

ILogger

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

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

EventSource

EventSource — это более старый высокопроизводительный API трассировки с структурированным ведением журнала. Изначально он был разработан для интеграции хорошо с трассировкой событий для Windows (ETW), но позже был расширен для поддержки кроссплатформенной трассировки EventPipe и EventListener для пользовательских приемников. По сравнению с ILogger, EventSource имеет относительно мало предварительно созданных приемников ведения журнала и не поддерживает встроенную поддержку настройки с помощью отдельных файлов конфигурации. EventSource отлично подходит, если требуется более жесткий контроль над интеграцией ETW или EventPipe , но для ведения журнала ILogger общего назначения более гибкий и удобный для использования.

Трассировка

System.Diagnostics.Trace и System.Diagnostics.Debug есть . Самые старые API ведения журнала NET. Эти классы имеют гибкие API конфигурации и большую экосистему приемников, но поддерживают только неструктурированное ведение журнала. В платформа .NET Framework их можно настроить с помощью файла app.config, но в .NET Core нет встроенного механизма конфигурации на основе файлов. Обычно они используются для создания диагностика выходных данных для разработчика при выполнении под отладчиком. Команда .NET продолжает поддерживать эти API для обеспечения обратной совместимости, но новые функции не будут добавлены. Эти API являются прекрасным выбором для приложений, которые уже используют их. Для новых приложений, которые еще не были зафиксированы в API ведения журнала, ILogger могут предложить лучшие функциональные возможности.

Специализированные API ведения журнала

Консоль

Класс System.Console имеет Write методы и WriteLine методы, которые можно использовать в простых сценариях ведения журнала. Эти API очень легко приступить к работе, но решение не будет столь гибким, как API ведения журнала общего назначения. Консоль разрешает только неструктурированное ведение журнала и не поддерживает настройку, чтобы выбрать, какие сообщения журнала включены или перенацелиться на другой приемник. Использование API ILogger или Trace с приемником консоли не занимает много дополнительных усилий и позволяет настроить ведение журнала.

DiagnosticSource

System.Diagnostics.DiagnosticSource предназначен для ведения журнала, в котором сообщения журнала будут анализироваться синхронно в процессе, а не сериализуются в любое хранилище. Это позволяет источнику и прослушивателю обмениваться произвольными объектами .NET в виде сообщений, в то время как большинство API ведения журнала требуют сериализации события журнала. Этот метод также может быть очень быстрым, обрабатывая события журнала в десятках наносекунд, если прослушиватель реализован эффективно. Средства, использующие эти API, часто действуют как профилировщики в процессе, хотя API не накладывает никаких ограничений.

EventLog

System.Diagnostics.EventLog — это только API Windows, который записывает сообщения в журнал событий Windows. Во многих случаях использование ILogger с необязательным приемником EventLog при работе в Windows может дать аналогичные функции без тесной связи приложения с ОС Windows.