В области информационных технологий и управления системами , управление производительностью приложений ( APM ) является мониторинг и управление производительностью и доступности программных приложений. APM стремится обнаруживать и диагностировать сложные проблемы с производительностью приложений, чтобы поддерживать ожидаемый уровень обслуживания . APM - это «перевод ИТ-показателей в бизнес-значение ([то есть] ценность)». [1]
Измерение производительности приложений
Внимательно отслеживаются два набора показателей производительности. Первый набор показателей производительности определяет производительность конечных пользователей приложения. Одним из примеров производительности является среднее время отклика при пиковой нагрузке. В состав набора входят время загрузки и время отклика.
- Нагрузка - это объем транзакций, обрабатываемых приложением, например транзакций в секунду (tps), запросов в секунду, страниц в секунду. Без компьютерной загрузки, требующей поиска, вычислений, передачи и т. Д., Большинство приложений работают достаточно быстро, поэтому программисты могут не уловить проблемы с производительностью во время разработки.
- Время отклика - это время, необходимое приложению для реакции на действия пользователя при такой нагрузке. [2]
Второй набор показателей производительности измеряет вычислительные ресурсы, используемые приложением для нагрузки, указывая, есть ли достаточная мощность для поддержки нагрузки, а также возможные места узких мест в производительности. Измерение этих количеств устанавливает эмпирическую базу производительности для приложения. Затем базовый уровень можно использовать для обнаружения изменений в производительности. Изменения производительности можно соотнести с внешними событиями и впоследствии использовать для прогнозирования будущих изменений производительности приложений. [3]
Использование APM является обычным для веб-приложений, которые лучше всего подходят для более подробных методов мониторинга. [4] Помимо измерения времени отклика для пользователя, можно также отслеживать время отклика для компонентов веб-приложения, чтобы помочь точно определить причины задержки. Также существуют устройства HTTP, которые могут декодировать время отклика, зависящее от транзакции, на уровне веб-сервера приложения.
В своей концептуальной основе APM , Gartner Research описывает пять измерений APM: [5] [6] [7] [8]
- Мониторинг взаимодействия с конечным пользователем - ( активный и пассивный )
- Обнаружение и моделирование архитектуры среды выполнения приложений
- Определяемое пользователем профилирование транзакций (также называемое управлением бизнес-транзакциями )
- Мониторинг компонентов приложения
- Отчетность и аналитика данных приложений
В 2016 году Gartner Research обновила свое определение по трем основным функциональным параметрам: [9]
- Мониторинг взаимодействия с конечным пользователем (EUEM) был преобразован в мониторинг цифрового опыта (DEM);
- Новое измерение, обнаружение, отслеживание и диагностика приложений (ADTD), объединяет три ранее отдельных измерения (обнаружение и визуализация топологии приложения [архитектура времени выполнения], профилирование пользовательских транзакций и подробное описание компонентов приложения), поскольку все три в первую очередь ориентированы на по устранению проблем и связаны между собой;
- Аналитика приложений (AA).
В 2019 году исследователи из Королевского технологического института KTH , Гарвардской школы бизнеса , Мюнхенского технического университета и BMW провели исследование, в котором основное внимание уделялось проблеме отсутствия надежных возможностей обнаружения аномалий и методов анализа первопричин в существующих решениях APM. Большинство требует ручных усилий и знания предметной области. Они разработали модель неконтролируемого машинного обучения на основе плотности для обнаружения аномалий в корпоративном приложении на основе данных из нескольких систем APM. Используя данные приложения в реальном времени за два месяца, они показывают, что модель обнаруживает ненормальное поведение системы более надежно, чем обычно используемый метод обнаружения выбросов, и предоставляет информацию для обнаружения основных причин [10] .
Актуальные вопросы
С первой половины 2013 года APM вступила в период интенсивной конкуренции технологий и стратегий с множеством поставщиков и точек зрения. [11] Это вызвало потрясения на рынке: поставщики, не имеющие отношения к делу (включая мониторинг сети, управление системами, инструментарий приложений и мониторинг производительности в Интернете), начали использовать обмен сообщениями вокруг APM [ какой? ] . В результате термин APM стал размытым и превратился в концепцию управления производительностью приложений на многих различных вычислительных платформах, а не на одном рынке. [ требуется пояснение ] [12] При таком большом количестве поставщиков выбор может оказаться сложной задачей. Важно тщательно оценить каждый, чтобы убедиться, что его возможности соответствуют вашим потребностям. [13]
При внедрении APM возникают две проблемы: (1) может быть сложно инструментировать приложение для мониторинга производительности приложения, особенно среди компонентов приложения, и (2) приложения могут быть виртуализированы , что увеличивает вариабельность измерений. [14] [15] Для решения первой проблемы управление сервисами приложений (ASM) обеспечивает ориентированный на приложения подход, в котором прозрачность производительности бизнес-сервисов является ключевой задачей. Второй аспект, присутствующий в распределенных, виртуальных и облачных приложениях, представляет собой уникальную проблему для мониторинга производительности приложений, поскольку большинство ключевых компонентов системы больше не размещаются на одной машине. Теперь каждая функция, вероятно, была разработана как Интернет-сервис, работающий в нескольких виртуализированных системах. Сами приложения, скорее всего, будут перемещаться из одной системы в другую для достижения целей уровня обслуживания и устранения кратковременных сбоев. [16]
Концептуальная основа APM
Сами приложениями становится все труднее управлять по мере их перехода к высоко распределенным, многоуровневым, многоэлементным конструкциям, которые во многих случаях полагаются на среды разработки приложений, такие как .NET или Java. [17] Концептуальная структура APM была разработана, чтобы помочь определить приоритеты подхода к тому, на чем сосредоточиться в первую очередь для быстрой реализации и общего понимания пятимерной модели APM. На слайде, посвященном структуре, выделяются три основных направления для каждого измерения и описаны их потенциальные преимущества. Эти области ниже обозначены как « Основные », а измерения с более низким приоритетом - как « Вторичные » [18].
Опыт конечного пользователя (первичный)
Измерение транзита трафика от пользовательского запроса к данным и обратно является частью сбора информации об опыте конечного пользователя (EUE). [19] Результат этого измерения называется мониторингом приложений в реальном времени (также известный как мониторинг сверху вниз), который состоит из двух компонентов: пассивного и активного. Пассивный мониторинг обычно представляет собой устройство без агентов, реализованное с использованием зеркалирования сетевых портов . Ключевой особенностью, которую следует учитывать, является возможность поддержки многокомпонентной аналитики (например, базы данных, клиента / браузера). С другой стороны, активный мониторинг состоит из синтетических зондов и веб-роботов, заранее определенных для отчетов о доступности системы и бизнес-транзакциях. Активный мониторинг - хорошее дополнение к пассивному мониторингу; Вместе эти два компонента помогают контролировать работоспособность приложения в непиковые часы, когда объем транзакций невелик.
Управление взаимодействием с пользователем (UEM) - это подкатегория, возникшая из измерения EUE для отслеживания поведенческого контекста пользователя. UEM, как это практикуется сегодня, выходит за рамки доступности и позволяет фиксировать задержки и несоответствия при взаимодействии людей с приложениями и другими службами. [20] UEM обычно основывается на агентах и может включать внедрение JavaScript для мониторинга на устройстве конечного пользователя. UEM считается еще одним аспектом мониторинга приложений в реальном времени.
Архитектура исполняемого приложения (вторичная)
Предложения по обнаружению приложений и сопоставлению зависимостей (ADDM) предназначены для автоматизации процесса сопоставления транзакций и приложений с базовыми компонентами инфраструктуры. [21] При подготовке к реализации архитектуры приложения во время выполнения необходимо убедиться, что для всех узлов и серверов в среде существует восходящий / нисходящий мониторинг (также известный как восходящий мониторинг). Это помогает заложить основу для корреляции событий и обеспечивает основу для общего понимания того, как топологии сети взаимодействуют с архитектурами приложений.
Бизнес-операция (первичная)
Сосредоточьтесь на пользовательских транзакциях или определениях URL-страниц, которые имеют какое-то значение для бизнес-сообщества. Например, если для данного приложения существует от 200 до 300 уникальных определений страниц, сгруппируйте их в 8-12 категорий высокого уровня. Это позволяет составлять содержательные отчеты SLA и предоставляет информацию о тенденциях в производительности приложений с точки зрения бизнеса: начните с широких категорий и со временем уточняйте их. Для более глубокого понимания см. Управление бизнес-транзакциями .
Мониторинг компонентов глубокого погружения (вторичный)
Мониторинг компонентов Deep Dive (DDCM) требует установки агента и, как правило, ориентирован на промежуточное программное обеспечение с упором на веб-серверы, серверы приложений и обмена сообщениями. Он должен обеспечивать представление стеков J2EE и .NET в реальном времени , связывая их с бизнес-транзакциями, определяемыми пользователем. Надежный монитор показывает четкий путь от выполнения кода (например, spring и struts) до отображаемого URL-адреса и, наконец, до пользовательского запроса. Поскольку DDCM тесно связан со вторым измерением модели APM, большинство продуктов в этой области также предоставляют отображение зависимостей обнаружения приложений (ADDM) как часть своего предложения.
Аналитика / отчетность (первичная)
Важно прийти к общему набору показателей для сбора и составления отчетов для каждого приложения, а затем стандартизировать общее представление о том, как представлять данные о производительности приложения. Сбор необработанных данных из других наборов инструментов в модели APM обеспечивает гибкость в отчетности приложений. Это позволяет отвечать на самые разные вопросы о производительности по мере их возникновения, несмотря на разные платформы, на которых может работать каждое приложение. Слишком много информации ошеломляет. Вот почему важно, чтобы отчеты были простыми, иначе они не будут использоваться. [22]
Программное обеспечение APM
- Blackfire Profiler
- Граница
- Эластичный НВ
- Instana
- JumpSoft
- Программное обеспечение SmartBear
- Stackify
- AppDynamics
Смотрите также
- Измерение отклика приложений
- Управление сервисом приложений
- Выполнение бизнес-транзакций
- Список инструментов анализа производительности
- Управление сетью
- Мониторинг веб-сайтов
Рекомендации
- ^ Драгич, Ларри (4 апреля 2012). «Анатомия APM - 4 основополагающих элемента успешной стратегии» . Дайджест APM.
- ^ Дуби, Дениз (11 ноября 2006 г.). «Управление эффективностью с точки зрения клиента» . NetworkWorld . Проверено 22 марта 2013 года .
- ^ Драгич, Ларри (11 мая 2012 г.). «APM и MoM - наборы симбиотических решений» . Дайджест APM.
- ^ «Что следует знать об APM - Часть 1» . NEXUS в реальном времени. 2013. Архивировано из оригинала на 2013-12-14.
- ^ «Сохраняйте пять функциональных измерений APM отчетливыми» . Gartner Research (идентификационный номер = G00206101). 16 сентября 2010 г.
- ^ «Аналитика против APM» . Дайджест APM. 28 января 2013 г.
- ^ «Сравнение пакетов управления производительностью приложений от CA, HP и Oracle» (PDF) . Малиновая консалтинговая группа . Проверено 22 марта 2013 года .
- ^ «Магический квадрант для мониторинга производительности приложений» . Gartner . Проверено 18 декабря 2013 года .
- ^ «Магический квадрант для пакетов мониторинга производительности приложений, 2016» . Gartner Research (идентификационный номер = G00298377). 21 декабря 2016.
- ^ Эльснер; Алеатрати Хосрошахи; MacCormack; Lagerström (январь 2019 г.). «Многомерное неконтролируемое машинное обучение для обнаружения аномалий в корпоративных приложениях» . Proc. 52-й Гавайской международной конференции по системным наукам (HICSS). DOI : 10.24251 / HICSS.2019.703 . Дата обращения 4 мая 2021 . Цитировать журнал требует
|journal=
( помощь ) - ^ «Конвергенция APM: мониторинг против управления» . Дайджест APM. 6 марта 2013 г.
- ^ «Спектр управления производительностью приложений» (PDF) . TRAC Research. 11 марта 2013 г. Архивировано 17 апреля 2013 г. из оригинального (PDF) .
- ^ «5 возможностей, которые следует учитывать при выборе решения для мониторинга производительности приложений» . APMdigest - Управление производительностью приложений . 2017-04-03 . Проверено 26 сентября 2017 .
- ^ Ханна, Гунджан; Beaty, Kirk A .; Кар, Гаутам; Кочут, Анджей (2006). «Управление производительностью приложений в виртуализированной серверной среде». Симпозиум по сетевым операциям и управлению, 2006. NOMS 2006. 10-й IEEE / IFIP : 373–381. DOI : 10,1109 / NOMS.2006.1687567 . ISBN 978-1-4244-0142-0.
- ^ Матчетт, Майк. «Неужели виртуализация тормозит из-за производительности?» . Обзор виртуализации . Проверено 22 марта 2013 года .
- ^ «Различия подходов к APM - чат с Джесси Ротштейном из Extrahop» . ZDNet. 9 декабря 2011 г.
- ^ «Пять основных элементов мониторинга производительности приложений» . NEXUS в реальном времени. 2010 г.
- ^ «Приоритет модели APM Gartner: концептуальная основа APM» . Дайджест APM. 15 марта 2012 г.
- ^ «Инструменты мониторинга производительности приложений: три стратегии поставщиков» . SearchNetworking. 25 марта 2013 г.
- ^ «Взгляд на панель управления взаимодействием с пользователем в Бостоне» . Дайджест APM. 23 марта 2012 г.
- ^ «Исследования и рынки: радар для обнаружения приложений и сопоставления зависимостей (ADDM)» . Деловой провод. 19 мая 2011 г.
- ^ «Большие данные и расширенная аналитика: истории успеха с первых линий» . Forbes . 3 декабря 2012 г.