Управление производительностью приложений

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

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

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

Второй набор метрик производительности фиксирует вычислительные ресурсы, используемые приложением при данной нагрузке, позволяя определить, хватает ли ресурсов для обработки заданных объёмов данных и где может возникнуть «узкое место» производительности. Измерения этих параметров позволяют сформировать эмпирическую производственную базовую линию для приложения. Она затем служит для обнаружения изменений производительности. Изменения производительности могут коррелироваться с внешними событиями, что создаёт возможность прогнозировать будущие изменения в поведении приложения^[4].

Использование APM особенно характерно для веб-приложений, что связано с возможностью глубокого и детального мониторинга^[5]. Помимо оценки времени отклика для пользователя, можно также отслеживать время отклика отдельных компонентов веб-приложения с целью выявления причин задержек. Существуют также HTTP-аппараты, позволяющие декодировать связанное с транзакцией время отклика на уровне веб-сервера.

Современные подходы к APM включают безагентный мониторинг с использованием технологии eBPF. Она позволяет собирать данные о производительности (такие как латентность, пропускная способность и ошибки) напрямую из операционной системы на уровне ядра Linux без изменения кода приложения. В отличие от традиционных методов, eBPF не требует установки специфичных агентов или перезапуска приложений, обеспечивая автоматическое обнаружение сервисов и мониторинг в реальном времени с минимальными накладными расходами^[6]

Для мониторинга ключевых показателей также применяется методология Golden Signals. Данные для неё могут собираться с помощью eBPF, что позволяет получать необходимые сведения о производительности независимо от того, какие метрики, логи и трейсы генерирует само приложение^[7]

С первой половины 2013 года рынок управления производительностью приложений характеризуется интенсивной конкуренцией как в технологической, так и в стратегической сферах, с большим числом вендоров и различных взглядов на проблему^[8]. Это привело к заметной трансформации рынка — к управлению производительностью приложений стали обращаться поставщики из смежных областей (например, мониторинга сетей, управления системами, инструментирования приложений, мониторинга веб-производительности). В результате термин APM утратил строгость и превратился в концепцию управления производительностью приложений для множества вычислительных платформ, а не только для одной технологической ниши^[9]. Из-за большого числа поставщиков выбор подходящего решения становится сложнее. Необходимо очень внимательно выбирать инструменты, чтобы их возможности действительно соответствовали требованиям.

Среди ключевых проблем внедрения APM — (1) трудности инструментирования приложений для отслеживания производительности, особенно при взаимодействии компонентов, а (2) виртуализация приложений, которая увеличивает изменчивость показаний^[10][11]. В современных архитектурах первая проблема решается с помощью технологии eBPF, которая обеспечивает наблюдаемость с «нулевым инструментированием» (zero-instrumentation) без необходимости ручного изменения кода^[12][13]. Вторая проблема связана с тем, что современные облачные и распределённые приложения больше не размещаются на одном сервере — зачастую отдельные функции реализованы как сетевые сервисы, работающие на множестве виртуализированных платформ. Приложения могут динамически перемещаться между системами для достижения целей по обслуживанию и для преодоления временных сбоев^[14].

Развитие микросервисных архитектур и распределённых систем привело к появлению новых вызовов для APM. К ним относятся высокая кардинальность метрик и атрибутов, которая перегружает базы данных и увеличивает затраты на инфраструктуру^[15][16], а также сложность сквозной трассировки в гетерогенных средах, требующая ручной настройки при переходе через асинхронные границы^[15][17]. Кроме того, в гибридных и мультиоблачных средах возникает проблема фрагментации данных: телеметрия рассеивается по множеству платформ, что создаёт «слепые зоны» и приводит к задержкам при выявлении первопричин инцидентов из-за необходимости ручной корреляции логов^[18].

Сами приложения становятся всё более сложными для управления, поскольку строятся по принципу распределённых, многоуровневых, многокомпонентных систем и часто используют такие фреймворки как .NET и Java. Концептуальная модель APM помогает выстроить приоритеты внедрения — на первом этапе следует сосредоточиться на отдельных измерениях, соответствующих определённым целям и эффектам. На схеме модели представлены три основных фокуса для каждого измерения, их преимущества и области реализации. Фокусы с приоритетом помечены как «основные», с меньшим приоритетом — как «второстепенные»^[19].

В своей Концептуальной модели APM исследователи Gartner выделяют пять измерений менеджмента производительности приложений^[20][21][22]:

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

В 2016 году Gartner пересмотрела определение, выделив три основные функциональные области^[23]:

• Мониторинг пользовательского опыта (EUEM), эволюционировавший в мониторинг цифрового опыта (DEM), который включает мониторинг реальных пользователей (RUM), синтетический мониторинг и мониторинг конечных точек^[24][25];
• Новая область — обнаружение, трассировка и диагностика приложений (ADTD), объединяющая три ранее отдельных направления (обнаружение и визуализация архитектуры, профилирование пользовательских транзакций, глубокая диагностика компонентов), поскольку они все направлены на локализацию проблем и тесно связаны друг с другом;
• Аналитика приложений (AA).

Мониторинг цифрового опыта (DEM)

Измерение передачи трафика от пользовательского запроса к данным и обратно — часть мониторинга пользовательского опыта (EUE)^[26]. Результатом такого мониторинга является реал-тайм мониторинг приложений («мониторинг сверху вниз»), включающий пассивные и активные компоненты. Пассивный мониторинг — обычно агентное решение, реализующееся посредством зеркалирования портов сетевого оборудования. К важным функциям относится поддержка мультикомпонентной аналитики. В активном мониторинге используются синтетические пробы и веб-роботы для отчёта о доступности системы и бизнес-транзакций. Активный мониторинг хорошо дополняет пассивный — вместе эти методы обеспечивают видимость состояния приложения в периоды низкой активности.

Управление пользовательским опытом (UEM) — подкласс, выделившийся из мониторинга EUE, отвечающий за отслеживание поведенческого контекста пользователя. В современном понимании UEM охватывает не только доступность, но и задержки, и нестабильность, возникающие во взаимодействии пользователя с приложением и сервисами^[27]. UEM обычно реализуется через агенты, иногда с помощью внедрения JavaScript на стороне пользователя.

В дальнейшем концепция мониторинга опыта конечных пользователей эволюционировала в мониторинг цифрового опыта (DEM). Современная модель DEM включает мониторинг реальных пользователей (RUM), мониторинг конечных точек и синтетический мониторинг^[25][24]. При этом возможности синтетического мониторинга расширились и теперь охватывают мониторинг API, имитацию мобильных сетей и интеграцию с CI/CD-конвейерами^[28].

В 2026 году стандарт OpenTelemetry (OTel) стал общепринятым в индустрии: большинство ведущих коммерческих и open-source APM-вендоров, а также облачных провайдеров, поддерживают протокол OTLP как формат приёма данных первого класса^[35].

В 2026 году объём рынка управления производительностью приложений (APM) оценивается в 12—15,87 млрд долларов США^[36]. Рост рынка обусловлен массовым внедрением облачных и микросервисных архитектур, переходом на гибридные и мультиоблачные платформы, а также развитием практик DevOps и непрерывной доставки^[37].

Среди крупнейших игроков на рынке выделяются компании Datadog, New Relic, Dynatrace и Cisco/Splunk^[38][39]. В результате приобретения Splunk корпорацией Cisco платформа AppDynamics стала частью портфеля Splunk Observability. Интеграция AppDynamics в экосистему Splunk/Cisco направлена на создание единого решения для обеспечения комплексной наблюдаемости (full-stack observability)^[40][41].