Ведение журнала приложения

  • Статья

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

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

Примеры использования этих подходов см. в статье Добавление ведения журнала в приложение Service Fabric.

Пакет SDK для Application Insights

Azure Application Insights поставляется с широкими возможностями интеграции с Azure Service Fabric. Пользователи могут добавлять пакеты NuGet ИИ Service Fabric и получать данные и журналы, созданные и собранные готовыми к просмотру на портале Azure. Кроме того пользователям рекомендуется добавлять свои собственные данные телеметрии для диагностики и отладки своих приложений, а также получения сведения о самых используемых службах и частей приложений. Класс TelemetryClient в пакете SDK предоставляет много способов отслеживать данные телеметрии в приложении. Дополнительные сведения об инструментировании и добавлении Application Insights в приложение см. руководстве по наблюдению и диагностике приложений .NET

EventSource

Если вы создаете решение Service Fabric из шаблона в Visual Studio, в нем создается класс ServiceEventSource или ActorEventSource, производный от EventSource. При этом создается шаблон, в который вы можете добавлять события для конкретного приложения или службы. Имя EventSourceдолжно быть уникальным, поэтому потребуется изменить стандартное имя MyCompany-<solution>-<project>. Наличие нескольких определений EventSource с одинаковым именем приведет к возникновению проблемы во время выполнения. У каждого определенного события должен быть уникальный идентификатор. Если идентификатор не является уникальным, происходит сбой во время выполнения. Некоторые организации предварительно назначают для идентификаторов диапазоны значений, чтобы избежать конфликтов между командами разработчиков. Дополнительные сведения см. в блоге Вэнса (Vance) или в документации MSDN.

Ведение журнала ASP.NET Core

Очень важно тщательно спланировать методы инструментирования кода. Правильный план инструментирования позволит избежать потенциальной дестабилизации базы кода, которая повлечет за собой повторное инструментрирование кода. Чтобы снизить риск, вы можете применить библиотеку инструментирования, например Microsoft.Extensions.Logging, которая входит в Microsoft ASP.NET Core. ASP.NET Core предоставляет интерфейс ILogger, который можно подключить к любому поставщику, с минимальными изменениями существующего кода. Код ASP.NET Core можно использовать на платформах Windows, Linux и в полной версии .NET Framework, то есть код инструментирования будет полностью стандартизирован.

Дальнейшие действия

После выбора поставщика ведения журнала для инструментирования приложений и служб вам потребуется агрегировать журналы и события перед отправкой в любую платформу аналитики. См. дополнительные сведения об Application Insights и EventFlow, чтобы ознакомиться с некоторыми рекомендуемыми параметрами Azure Monitor.