Сравнение API-интерфейсов метрик

  • Статья

При добавлении нового инструментария метрик в приложение или библиотеку .NET можно выбрать нужный API из множества доступных. Сведения в этой статье помогут понять, какие API-интерфейсы доступны и какие компромиссы связаны с выбором необходимых.

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

Интерфейсы API .NET

За более чем 20-летнюю историю .NET мы несколько раз пересматривали структуру API-интерфейсов метрик, каждый из которых является поддерживаемым и не зависящим от поставщика.

System.Diagnostics.Metrics

API System.Diagnostics.Metrics — это новейшие кроссплатформенные API, разработанные в тесном сотрудничестве в рамках проекта OpenTelemetry. Если у вас нет определенной причины использовать один из старых API, описанных ниже, System.Diagnostics.Metrics является хорошим выбором по умолчанию для новой работы. Он доступен путем назначения .NET 6+ или более старых приложений .NET Core и платформа .NET Framework, добавив ссылку на пакет NuGet .NET System.Diagnostics.DiagnosticsSource 6.0+ NuGet. Помимо обеспечения широкой совместимости, этот API добавляет поддержку для многих вещей, которые не хватает от предыдущих API, таких как:

  • Гистограммы и процентили
  • Многомерные метрики
  • Строго типизированный высокопроизводительный API прослушивателя
  • Несколько одновременных прослушивателей
  • Доступ прослушивателя к неагрегированным измерениям

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

PerformanceCounter

API-интерфейсы System.Diagnostics.PerformanceCounter — это самые старые API-интерфейсы метрик. Они поддерживаются только в Windows и предоставляют управляемую программу-оболочку для технологии счетчиков производительности в ОС Windows. Они доступны во всех поддерживаемых версиях .NET.

Эти API предназначены в первую очередь для обеспечения совместимости. Команда разработчиков .NET считает, что это стабильный аспект, не требующий дальнейших улучшений (помимо исправления ошибок). Эти API-интерфейсы не предлагаются для использования в новых проектах разработки, если только проект не предназначен исключительно для Windows, и вы хотите работать с инструментами Счетчика производительности Windows.

Дополнительные сведения см. в статье Счетчики производительности в .NET Framework.

Счетчики событий

API счетчиков событий стал следующим после PerformanceCounters. Этот API призван обеспечить согласованность работы на разных платформах. API доступны путем назначения .NET Core 3.1 и более поздних версий, а небольшое подмножество доступно в платформа .NET Framework 4.7.1 и более поздних версий. Эти API-интерфейсы являются полностью поддерживаемыми и активно используются ключевыми библиотеками .NET, но обладают меньшей функциональностью по сравнению с более новыми API-интерфейсами System.Diagnostics.Metrics. Счетчики производительности могут информировать о средних значениях и скорости изменений, но не поддерживают гистограммы и процентили. Кроме того, отсутствует поддержка многомерных метрик. Использовать пользовательский инструментарий можно с помощью API EventListener, хотя он не является строго типизированным. Он предоставляет доступ только к агрегированным значениям и имеет ограничения при использовании нескольких прослушивателей одновременно. Счетчики событий поддерживаются напрямую в Visual Studio, Application Insights, dotnet-counters и dotnet-monitor. Чтобы узнать о поддержке сторонних средств, обратитесь к документации по поставщику или проекту.

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

Сторонние API-интерфейсы

У большинства поставщиков мониторинга производительности приложений (APM), таких как AppDynamics, Application Insights, DataDog, DynaTrace и NewRelic, API-интерфейсы метрик входят в состав библиотек инструментирования. Prometheus и AppMetrics также являются популярными проектами OSS .NET. Дополнительные сведения об этих проектах можно найти на соответствующих веб-сайтах.