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

В области информационных технологий и системного управления управление производительностью приложений ( APM ) — это мониторинг и управление производительностью и доступностью программных приложений. APM стремится обнаруживать и диагностировать сложные проблемы с производительностью приложений для поддержания ожидаемого уровня обслуживания . APM — это «перевод показателей ИТ в бизнес-смысл ([т. е.] ценность)». ^[1]

Измерение производительности приложений

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

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

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

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

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

В своей концептуальной структуре APM компания Gartner Research описывает пять аспектов APM: ^[5]^[6]^[7]^[8]

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

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

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

Текущие проблемы

С первой половины 2013 года APM вступила в период острой конкуренции в области технологий и стратегий с участием множества поставщиков и точек зрения. ^[10] Это вызвало переворот на рынке среди поставщиков с несвязанным опытом (включая мониторинг сети, ^[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 категорий высокого уровня. Это позволяет создавать содержательные отчеты по соглашениям об уровне обслуживания и предоставлять информацию о тенденциях производительности приложений с точки зрения бизнеса: начните с широких категорий и со временем уточняйте их. Для более глубокого понимания см. Управление бизнес-транзакциями .

Глубокий мониторинг компонентов (вторичный)

Мониторинг компонентов глубокого погружения (DDCM) требует установки агента и обычно ориентирован на промежуточное программное обеспечение , уделяя особое внимание веб-серверам, приложениям и серверам обмена сообщениями. Он должен обеспечивать просмотр стеков J2EE и .NET в режиме реального времени , связывая их с определяемыми пользователем бизнес-транзакциями. Надежный монитор показывает четкий путь от выполнения кода (например, Spring и Struts) до отображаемого URL-адреса и, наконец, до запроса пользователя. Поскольку DDCM тесно связан со вторым измерением модели APM, большинство продуктов в этой области также предоставляют отображение зависимостей обнаружения приложений (ADDM) как часть своих предложений.

Аналитика/отчетность (основная)

Важно прийти к общему набору показателей для сбора и составления отчетов для каждого приложения, а затем стандартизировать общее представление о том, как представлять данные о производительности приложения. Сбор необработанных данных из других наборов инструментов в модели APM обеспечивает гибкость в составлении отчетов о приложениях. Это позволяет отвечать на широкий спектр вопросов производительности по мере их возникновения, несмотря на разные платформы, на которых может работать каждое приложение. Слишком много информации утомляет. Вот почему важно, чтобы отчеты были простыми, иначе они не будут использоваться. ^[22]

См. также

Ссылки

^ Драгич, Ларри (4 апреля 2012 г.). «Анатомия APM – 4 основополагающих элемента успешной стратегии» . Дайджест АПМ.
^ Дуби, Дениз (11 ноября 2006 г.). «Управление эффективностью с точки зрения клиента» . Сетевой Мир . Проверено 22 марта 2013 г.
^ Драгич, Ларри (11 мая 2012 г.). «APM и MoM — наборы симбиотических растворов» . Дайджест АПМ.
^ «Что вам следует знать об APM – Часть 1» . НЕКСУС в реальном времени. 2013. Архивировано из оригинала 14 декабря 2013 г.
^ «Сохраняйте четкость пяти функциональных аспектов APM» . Gartner Research (идентификатор = G00206101). 16 сентября 2010 г. Архивировано из оригинала 11 июля 2011 г.
^ «Аналитика против APM» . Дайджест АПМ. 28 января 2013 г.
^ «Сравнение пакетов управления производительностью приложений от CA, HP и Oracle» (PDF) . Консалтинговая группа «Кримсон» . Проверено 22 марта 2013 г.
^ «Магический квадрант мониторинга производительности приложений» . Гартнер . Проверено 18 декабря 2013 г.
^ «Магический квадрант для пакетов мониторинга производительности приложений, 2016 г.» . Gartner Research (идентификатор = G00298377). 21 декабря 2016 г.
^ «Конвергенция APM: мониторинг против управления» . Дайджест АПМ. 6 марта 2013 г.
^ «Что такое сетевой мониторинг?» . Асцендент Технолоджис, Инк . 05.01.2022 . Проверено 9 января 2022 г.
^ «Спектр управления производительностью приложений» (PDF) . Исследование ПРОФ. 11 марта 2013 г. Архивировано из оригинала (PDF) 17 апреля 2013 г.
^ «5 возможностей, которые следует учитывать при выборе решения для мониторинга производительности приложений» . APMdigest — Управление производительностью приложений . 03.04.2017 . Проверено 26 сентября 2017 г.
^ Ханна, Гунджан; Бити, Кирк А.; Кар, Гаутама; Кочут, Анджей (2006). «Управление производительностью приложений в средах виртуализированных серверов». 2006 Симпозиум IEEE/IFIP по эксплуатации и управлению сетями NOMS 2006 . стр. 373–381. дои : 10.1109/NOMS.2006.1687567 . ISBN 978-1-4244-0142-0 . S2CID 14638468 .
^ Мэтчетт, Майк. «Остановилась ли виртуализация на производительности?» . Обзор виртуализации . Проверено 22 марта 2013 г.
^ «Различия между подходами к APM — беседа с Джесси Ротштейном из Extrahop» . ЗДНет. 9 декабря 2011 г. Архивировано из оригинала 18 апреля 2012 г.
^ «Пять основных элементов мониторинга производительности приложений» . НЕКСУС в реальном времени. 2010.
^ «Приоритеты модели APM Gartner: концептуальная основа APM» . Дайджест АПМ. 15 марта 2012 г.
^ «Инструменты мониторинга производительности приложений: три стратегии поставщиков» . Поиск в сети. 25 марта 2013 г.
^ «Информация от панели управления пользовательским опытом в Бостоне» . Дайджест АПМ. 23 марта 2012 г.
^ «Исследования и рынки: радар для обнаружения приложений и сопоставления зависимостей (ADDM)» . Деловой провод. 19 мая 2011 г.
^ «Большие данные и расширенная аналитика: истории успеха с передовой» . Форбс . 3 декабря 2012 г.

[1] Драгич, Ларри (4 апреля 2012 г.). «Анатомия APM – 4 основополагающих элемента успешной стратегии» . Дайджест АПМ.

[2] Дуби, Дениз (11 ноября 2006 г.). «Управление эффективностью с точки зрения клиента» . Сетевой Мир . Проверено 22 марта 2013 г.

[3] Драгич, Ларри (11 мая 2012 г.). «APM и MoM — наборы симбиотических растворов» . Дайджест АПМ.

[4] «Что вам следует знать об APM – Часть 1» . НЕКСУС в реальном времени. 2013. Архивировано из оригинала 14 декабря 2013 г.

[5] «Сохраняйте четкость пяти функциональных аспектов APM» . Gartner Research (идентификатор = G00206101). 16 сентября 2010 г. Архивировано из оригинала 11 июля 2011 г.

[6] «Аналитика против APM» . Дайджест АПМ. 28 января 2013 г.

[7] «Сравнение пакетов управления производительностью приложений от CA, HP и Oracle» (PDF) . Консалтинговая группа «Кримсон» . Проверено 22 марта 2013 г.

[8] «Магический квадрант мониторинга производительности приложений» . Гартнер . Проверено 18 декабря 2013 г.

[9] «Магический квадрант для пакетов мониторинга производительности приложений, 2016 г.» . Gartner Research (идентификатор = G00298377). 21 декабря 2016 г.

[10] «Конвергенция APM: мониторинг против управления» . Дайджест АПМ. 6 марта 2013 г.

[11] «Что такое сетевой мониторинг?» . Асцендент Технолоджис, Инк . 05.01.2022 . Проверено 9 января 2022 г.

[12] «Спектр управления производительностью приложений» (PDF) . Исследование ПРОФ. 11 марта 2013 г. Архивировано из оригинала (PDF) 17 апреля 2013 г.

[13] «5 возможностей, которые следует учитывать при выборе решения для мониторинга производительности приложений» . APMdigest — Управление производительностью приложений . 03.04.2017 . Проверено 26 сентября 2017 г.

[14] Ханна, Гунджан; Бити, Кирк А.; Кар, Гаутама; Кочут, Анджей (2006). «Управление производительностью приложений в средах виртуализированных серверов». 2006 Симпозиум IEEE/IFIP по эксплуатации и управлению сетями NOMS 2006 . стр. 373–381. дои : 10.1109/NOMS.2006.1687567 . ISBN 978-1-4244-0142-0 . S2CID 14638468 .

[15] Мэтчетт, Майк. «Остановилась ли виртуализация на производительности?» . Обзор виртуализации . Проверено 22 марта 2013 г.

[16] «Различия между подходами к APM — беседа с Джесси Ротштейном из Extrahop» . ЗДНет. 9 декабря 2011 г. Архивировано из оригинала 18 апреля 2012 г.

[17] «Пять основных элементов мониторинга производительности приложений» . НЕКСУС в реальном времени. 2010.

[18] «Приоритеты модели APM Gartner: концептуальная основа APM» . Дайджест АПМ. 15 марта 2012 г.

[19] «Инструменты мониторинга производительности приложений: три стратегии поставщиков» . Поиск в сети. 25 марта 2013 г.

[20] «Информация от панели управления пользовательским опытом в Бостоне» . Дайджест АПМ. 23 марта 2012 г.

[21] «Исследования и рынки: радар для обнаружения приложений и сопоставления зависимостей (ADDM)» . Деловой провод. 19 мая 2011 г.

[22] «Большие данные и расширенная аналитика: истории успеха с передовой» . Форбс . 3 декабря 2012 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]