Введение
Мониторинг и управление производительностью и доступностью программных приложений. В области информационных технологий и системного управления, управление производительностью приложений (APM) представляет собой мониторинг и управление производительностью и доступностью программных приложений. APM направлено на выявление и диагностику сложных проблем с производительностью приложений для поддержания ожидаемого уровня обслуживания. APM – это «преобразование ИТ-метрик в бизнес-ценность (т.е. в значимые для бизнеса показатели)».
In the fields of information technology and systems management, application performance management (APM) is the monitoring and management of the performance and availability of software applications. APM strives to detect and diagnose complex application performance problems to maintain an expected level of service. APM is "the translation of IT metrics into business meaning ([i. e.] value)."
Текущие вопросы
С первой половины 2013 года APM вступила в период острой конкуренции в технологиях и стратегиях с множеством поставщиков и различных подходов. Это привело к серьезным изменениям на рынке, когда компании из несмежных областей (таких как мониторинг сети, управление системами, инструментирование приложений и мониторинг веб-производительности) стали позиционировать себя в сфере APM. В результате термин APM потерял свою четкость и превратился в концепцию управления производительностью приложений на множестве различных вычислительных платформ, а не в отдельный рынок. При таком большом количестве поставщиков выбор подходящего может быть сложной задачей. Важно тщательно оценивать каждого, чтобы убедиться, что его возможности соответствуют вашим потребностям. Две основные проблемы при внедрении APM заключаются в том, что (1) бывает сложно настроить инструментирование приложения для мониторинга его производительности, особенно между его компонентами, и (2) виртуализация приложений повышает вариативность измерений. Для решения первой проблемы управление сервисами приложений (ASM) предлагает подход, ориентированный на приложения, где ключевой задачей является обеспечение видимости производительности бизнес-сервисов. Второй аспект, характерный для распределенных, виртуальных и облачных приложений, представляет собой уникальную проблему для мониторинга производительности, поскольку большинство ключевых системных компонентов больше не размещаются на одном сервере. Каждая функция теперь, скорее всего, реализована как интернет-сервис, работающий на нескольких виртуализированных системах. Сами приложения, вероятно, будут перемещаться между системами для достижения целевых показателей уровня обслуживания и устранения временных сбоев.
Концептуальные рамки ППМ
Сами приложения становятся все более сложными в управлении по мере перехода к высокораспределенным, многоуровневым, многокомпонентным архитектурам, которые во многих случаях опираются на фреймворки разработки приложений, такие как .NET или Java. Концептуальная модель APM была разработана, чтобы помочь расставить приоритеты и определить, с чего начать для быстрого внедрения и общего понимания пятимерной модели APM. На слайде модели представлены три области внимания для каждого измерения и описаны их потенциальные преимущества. Эти области обозначены как "Основные" ниже, а измерения с меньшим приоритетом – как "Вторичные".
Опыт конечного пользователя (первичный)
Измерение времени прохождения трафика от запроса пользователя к данным и обратно является частью оценки опыта конечного пользователя (EUE). Результат этого измерения называется мониторингом приложений в реальном времени (также известный как мониторинг "сверху вниз"), который состоит из двух компонентов: пассивного и активного. Пассивный мониторинг обычно реализуется в виде аппаратного обеспечения без агентов, использующего зеркалирование сетевых портов. Важной характеристикой является возможность поддержки многокомпонентной аналитики (например, баз данных, клиентских приложений/браузеров). Активный мониторинг, в свою очередь, включает в себя синтетические зонды и веб-роботы, предварительно настроенные для отслеживания доступности системы и выполнения бизнес-транзакций. Активный мониторинг хорошо дополняет пассивный; вместе эти два компонента обеспечивают видимость состояния приложений в периоды низкой нагрузки, когда объем транзакций невелик. Управление пользовательским опытом (UEM) – это подкатегория, выделившаяся из области EUE для мониторинга поведенческого контекста пользователя. Современные решения UEM выходят за рамки простого отслеживания доступности, фиксируя задержки и несоответствия при взаимодействии пользователей с приложениями и другими сервисами. UEM обычно основан на агентах и может включать в себя внедрение JavaScript для мониторинга устройства конечного пользователя. UEM рассматривается как еще одна грань мониторинга приложений в реальном времени.
Архитектура приложения в режиме выполнения (вторичная)
Существуют решения для обнаружения приложений и построения карт зависимостей (ADDM), позволяющие автоматизировать процесс сопоставления транзакций и приложений с базовыми компонентами инфраструктуры. При подготовке к внедрению архитектуры приложения, работающего в реальном времени, необходимо обеспечить мониторинг доступности всех узлов и серверов в среде (также известный как мониторинг «снизу вверх»). Это помогает создать основу для корреляции событий и обеспечивает общее понимание взаимодействия сетевых топологий с архитектурами приложений.
Деловая операция (первичная)
Сосредоточьтесь на транзакциях, определенных пользователями, или на определениях страниц URL, которые имеют практическое значение для бизнеса. Например, если для данного приложения существует от 200 до 300 уникальных определений страниц, сгруппируйте их в 8–12 категорий верхнего уровня. Это позволит формировать содержательные отчеты об уровне соглашения об обслуживании (SLA) и получать информацию о динамике производительности приложений с точки зрения бизнеса: начните с широких категорий и постепенно уточняйте их. Для получения более подробной информации обратитесь к разделу "Управление бизнес-транзакциями".
Мониторинг глубокого погружения (вторичный)
Мониторинг компонентов с глубоким погружением (DDCM) требует установки агента и обычно ориентирован на промежуточное программное обеспечение, в частности на веб-, прикладные и серверы обмена сообщениями. Он должен обеспечивать представление в реальном времени стеков J2EE и .NET, связывая их с бизнес-транзакциями, определенными пользователем. Надежная система мониторинга отображает четкий путь от выполнения кода (например, Spring и Struts) до отображаемого URL и, в конечном итоге, до запроса пользователя. Поскольку DDCM тесно связан со вторым измерением в модели APM, большинство продуктов в этой области также предоставляют функциональность автоматического обнаружения и построения карт зависимостей приложений (ADDM) как часть своего предложения.
Аналитика/отчетность (первичная)
Важно определить единый набор метрик для сбора и отчётности по каждому приложению, а затем стандартизировать представление данных о производительности приложений. Сбор необработанных данных из различных инструментов в рамках APM-модели обеспечивает гибкость в формировании отчётов. Это позволяет отвечать на широкий спектр вопросов о производительности, независимо от платформ, на которых работают приложения. Избыток информации затрудняет анализ. Поэтому важно, чтобы отчёты были простыми и понятными, иначе они останутся невостребованными.