Мониторинг приложений в стиле SaaS

• базовую проверку доступности хостов (ping) и веб-страниц (HTTP GET);
• проверку корректности разрешения DNS-имён, доступности TCP-портов;
• расширенное, «сценарное» тестирование веб-приложений, например, проверка входа в приложение по специальному тестовому логину/паролю, работоспособности выбранных сервисов – получения выписки со счёта в интернет-банке или подключения новой услуги в личном кабинете интернет-провайдера;
• предоставление дополнительной информации в случае проблем, например, кодов ошибок HTTP, маршрута (trace route) до вашего сервера, информации о проблемах с разрешением имён (DNS).

При этом развёртывание традиционной, не облачной, «синтетики» для качественного мониторинга современных веб-приложений – достаточно затратное мероприятие, т.к. придётся решать вопросы с размещением тестирующего ПО в различных сетевых локациях.

Рис. 1. Магический квадрант Gartner – Application Monitoring (октябрь 2014 г.)

Полнофункциональный мониторинг приложений. Все основные производители предоставляют возможность глубокого мониторинга современных приложений, работающих на Java или .NET (некоторые поддерживают и другие платформы – PHP, node.js и др.).

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

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

Ниже перечислены основные возможности современных облачных систем мониторинга приложений:

• анализ метрик производительности виртуальной машины (Java JVM/.NET CLR);
• анализ метрик производительности ОС с помощью установки дополнительного агентского ПО. Обычно обеспечивается базовый набор метрик, которого, впрочем, достаточно во многих случаях: утилизация CPU, памяти, дисков, сетевых интерфейсов, базовые метрики работы процессов (CPU, диск, IO);
• сбор подробной информации о выполненных транзакциях (в том числе полное время выполнения транзакции, количество вызовов за период времени, ошибки времени выполнения, трассировка стека, выявление блоков кода, выполнение которых занимает наибольшее время). Кроме того, проводится анализ запросов к БД, осуществленных приложением, и взаимодействия приложения с очередями сообщений и внешними сервисами;
• расчёт baseline («базовых линий» – нормальных значений метрик). Рассчитанные значения используются для мониторинга нескольких сценариев:

1. 1. сравнение релизов – как изменилась производительность приложения после обновления версии;
   2. поиск первопричины – при изучении проблем можно провести анализ метрик всех компонент, участвующих в выполнении транзакции. Например, анализируя ошибки приложения вида «Сервис временно недоступен», можно посмотреть, какие показатели ОС, JVM или БД в это время выходили за пределы своих нормальных значений. ПО от некоторых вендоров может выполнять такую аналитику автоматически;
   3. оповещение – отправка уведомлений в случае выхода ключевых метрик из коридора нормальных значений;

• мониторинг действий реальных пользователей. Чтобы выяснить, насколько быстро и качественно работает веб- приложение с точки зрения конечных пользователей, инструменты облачного мониторинга обычно полагаются на вставку дополнительного кода в генерируемые приложением HTML-страницы. Внедряемые скрипты замеряют время отрисовки страниц и исполнения клиентских скриптов, отправляя полученные данные напрямую из браузера пользователя в облако. Эта информация помогает проанализировать работу приложения «из конца в конец» – выявить проблемы у пользователей и связать их с проблемами в инфраструктуре или коде приложения;
• мониторинг мобильных приложений (iOS, Android). Для анализа их функционирования разработчик приложений может воспользоваться предоставляемым SDK (Software Development Kit) – после перекомпиляции мобильного приложения с внедрённым кодом вендора в облако могут отправляться следующие данные: подробная информация о мобильном устройстве, о географическом местоположении пользователя и используемом операторе связи для выявления проблем, специфичных для региона или конкретного оператора, о блоках кода, время выполнения которых занимает наибольшее время. Также в облако идут данные об ошибках, падениях мобильного приложения и проблемах взаимодействия с back-end’ом по сети.

Рис. 2. Страница статуса приложения в HP AppPulse Active

Облачные решения по мониторингу

Российским компаниям доступно большое количество облачных систем мониторинга, рассмотрим лишь некоторые из них.

HP AppPulse. Линейка продуктов HP App-Pulse (ранее – HP Performance Anywhere) состоит из облачного ПО, доступного к использованию на портале Pronq (www.pronq.com). Линейка постоянно расширяется и на данный момент состоит из большого числа отдельных продуктов, однако к нашей теме имеет отношение лишь их часть.

HP AppPulse Active – наверное, один из самых функциональных продуктов синтетического мониторинга на рынке: поддерживается тестирование веб-страниц, доступности хостов и TCP-портов, серверов DNS и FTP. Даже в базовом режиме тестирования веб-сайта есть возможность проверки содержимого: вы можете убедиться, что в тексте страницы, которую увидит пользователь, отсутствует, например, слово «ошибка».

Сценарное тестирование веб-приложений реализовано с помощью выполнения скриптов, записанных в среде разработки HP Vugen. HP Vugen позволяет записать действия пользователя, выполняемые в браузерах Firefox и IE, после этого среда разработки сгенерирует скрипт, который впоследствии легко можно доработать.

Тестовые скрипты можно выполнять как из множества облачных локаций, расположенных по всему миру (в России, впрочем, пока их нет), так и из закрытого сетевого контура компании (для этого требуются скачивание и установка дополнительного модуля). На основе собранных значений метрик доступности и производительности веб-ресурсов ПО позволяет создавать SLA, а также автоматически выявлять отклонения от нормы (Predictive Analytics).

Судя по всему, «под капотом» HP AppPulse Active трудится старый знакомый – HP Business Process Monitor, поэтому если у вас уже есть готовые скрипты, созданные для HP BPM или HP LoadRunner, их можно загрузить в ПО и сразу начать мониторинг. Поддерживаются, впрочем, не все типы скриптов, а только те, которые имеют отношение к тестированию интернет-ресурсов.

HP AppPulse Diagnostics обеспечивает мониторинг приложений Java/.NET/Python. Возможности продукта практически повторяют функционал обычного, не облачного HP Diagnostics. Поддерживаются профилирование транзакций, выявление отклонений в скорости их выполнения от нормы (Predictive Analytics), автоматический поиск первопричин задержек в работе транзакций (проблемы ОС/среды исполнения, внешних сервисов, БД или конкретных блоков кода).

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

HP AppPulse Mobile отвечает за мониторинг мобильных приложений. AppPulse Mobile SDK легко внедряется в ПО для смартфонов и не требует модификации кода. После перекомпиляции и распространения приложения на странице AppPulse Mobile станут доступны данные о его работе на устройствах пользователей. Собирается информация о задержках в реакции на пользовательские действия и фактах падения приложения. На основе этих данных рассчитывается интегральный показатель FunDex (по аналогии с широко используемым Apdex), который показывает, насколько среднестатистический пользователь может быть доволен работой мобильного ПО.

В случае падения приложения AppPulse Mobile предоставит пошаговый сценарий действий пользователя, которые привели к такому печальному результату, что, безусловно, поможет в поиске и исправлении ошибок. Собранная информация о конфигурации смартфонов пользователей поможет узнать, например, на каких версиях ОС проблемы случаются чаще всего.

Каждый продукт из линейки HP AppPulse работает сам по себе, интеграции между ними не предусмотрено. Например, потенциально вы сможете узнать, что первопричина «задумчивости» мобильного приложения заключается в медленной генерации данных back-end’ом, но корреляцию вам придётся провести самостоятельно, заглядывая поочередно в консоли HP AppPulse Diagnostics и HP AppPulse Mobile.

Рис. 3. Страница статуса мониторинга мобильного приложения в HP AppPulse Mobile

New Relic. Облачное ПО мониторинга от компании New Relic включает в себя полный набор инструментов для синтетического мониторинга, мониторинга приложений Java/.NET/PHP/Python/Ruby/Node.js, ОС серверов, ПО для смартфонов, действий реальных пользователей. В нем реализованы практически все современные возможности, включая мониторинг распределённых (между несколькими приложениями) транзакций, построение карты приложения, профилирование потоков и др.

Стоит отметить, что New Relic поддерживает расчёт интегрального индекса Apdex как для приложений целиком, так и для отдельных транзакций. Apdex отражает степень удовлетворённости реальных пользователей скоростью и стабильностью работы приложения. При уменьшении индекса можно сделать вывод о наличии проблем с мобильным ПО, что предполагает дальнейшие шаги по выявлению их корневых причин.

«Синтетика» в базовом варианте может только проверять доступность страниц (опционально доступна загрузка всех их элементов). Для сценарного тестирования сайтов придётся создавать скрипты на JavaScript (используется скриптовый браузер Selenium), возможность записать действия пользователя не предусмотрена. Локаций, откуда могут запускаться тесты, пока тоже не очень много – порядка десятка, ближайшая к нам находится в Германии. «Синтетика» работает обособленно и никак не связана с мониторингом работы приложений.

Конструктор dashboard’ов нам понравился – простой и гибкий, он позволяет визуализировать достаточно сложные данные (по логике расчёта). Для получения данных мониторинга необходимо построить SQL-запрос в полуавтоматическом режиме, при этом система подсказывает все возможные варианты ключевых слов и значений колонок таблиц.

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

В ПО мониторинга New Relic можно отправлять собственные метрики и события с помощью API системы. На этой возможности основываются расширения (plugins), которые используются для включения в контур мониторинга дополнительных элементов ИТ-инфраструктуры, таких как ПО веб-серверов или баз данных. На момент написания статьи на сайте New Relic было размещено уже более 100 расширений, созданных партнёрами компании.

Рис. 4. Основная страница «синтетики» в New Relic

Рис. 5. Разработка dashboard в New Relic

AppDynamics. ПО обеспечивает мониторинг приложений Java/.NET/PHP/ Node.js, мобильных приложений, ОС серверов, баз данных. Для синтетического мониторинга AppDynamics не предоставляет своего решения, опираясь на интеграцию с продуктами компании Apica. Мониторинг реальных пользователей воз-можен либо через внедрение дополнительного кода в веб-страницы, либо через интеграцию с ПО BMC End User Experience Management.

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

Отличительной особенностью платформы от AppDynamics является возможность ее работы как в облачном, так и в обычном (on-premise) режиме: вы можете скачать серверное ПО и установить его на своей виртуальной или физической инфраструктуре, решив много проблем с безопасностью и при этом не потеряв в функциональности.

При мониторинге приложений компания AppDynamics, в отличие от New Relic, не использует индекс Apdex для интегральной оценки качества работы программ (она даже опубликовала критическую статью1 о самой идее этого индекса). Вместо этого ПО рассчитывает базовые линии для всех метрик, а механизм выявления аномалий постоянно сравнивает текущие показатели с нормальными, выявляя проблемные элементы. ПО предоставляет возможность эффективного исследования проблем с производительностью: в случае обнаружения аномального поведения какого-либо компонента приложения автоматически выявляются все метрики связанных элементов инфраструктуры, которые тоже ведут себя не так, как обычно. Этот удобно реализованный функционал позволяет быстро и точно выявлять корневые причины проблем доступности и производительности.

В модуле мониторинга приложений AppDynamics удалось реализовать очень удачное, на наш взгляд, их основное представление – карту. Она отображает текущие взаимосвязи между модулями распределенных приложений (аналог сервисно-ресурсной модели, только обновляющейся в режиме реального времени), включая экземпляры БД, очереди сообщений и серверы. Карта содержит большое количество интерактивной диагностической информации, при этом не выглядит перегруженной и может быть использована как основное представление для операторов мониторинга.

Еще одной «фишкой» ПО является корректный анализ работы асинхронных транзакций и транспорта Web Sockets – эти технологии всё чаще используются в современных веб-сервисах.

Модуль мониторинга мобильного ПО выгодно отличает интеграция с основным модулем – мониторинга приложений. В случае задержек в работе мобильного приложения вы получите информацию о том, как вели себя соответствующие транзакции в back-end’е.

Дополнительные возможности предоставляют war rooms – коллективные обсуждения данных мониторинга с другими пользователями системы в режиме чата. Очень полезно, когда информация, которой обмениваются сотрудники по ходу решения проблем, остаётся в системе с привязкой к конкретной временной точке и компоненту приложения.

AppDynamics предлагает воспользоваться расширениями, которые разрабатывают как компании, так и частные разработчики. Можно найти, например, расширения для мониторинга VMware WebSphere MQ.

Рис. 6. Карта и основные метрики приложения в AppDynamics

Рис. 7. Автоматический поиск метрик с аномальными значениями в AppDynamics

Плюсы и минусы облачного мониторинга

Чем отличаются облачные продукты мониторинга от своих традиционных собратьев, требующих развёртывания на площадке компании? К плюсам SaaS ПО для мониторинга приложений стоит отнести несколько факторов.

Быстрое развёртывание. В нашей тестовой лаборатории, как правило, уходило менее часа на то, чтобы получить первые данные мониторинга с помощью типичного представителя облачного ПО. Еще 60 минут было достаточно, для того чтобы познакомиться с интерфейсом и основными компонентами системы, а в течение третьего часа мы уже были способны создавать свои представления (dashboards), настраивать под себя схему оповещений и определять SLA.

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

Между «облачниками» наблюдается серьезная конкуренция, поэтому борьба за клиента идёт по всем направлениям, производители не могут позволить себе «задумчивость» интерфейса и поверхностную, отстающую от реальности документацию (это, увы, мы пока сплошь и рядом встречаем у традиционных продуктов мониторинга). Интерфейс ПО всех вендоров, упомянутых в статье, очевиден, понятен, современен. Продуктами пользоваться удобно (а значит, эффективно) и попросту приятно.

Отсутствие проблем с поддержкой ПО, обновлениями, резервным копированием. Их берёт на себя вендор облачного решения, снижая затраты компании на поддержку системы мониторинга. Большая часть работ по обновлению ПО проходит для пользователей совершенно незаметно. Некоторые вендоры выделяют 2–3 часа в месяц на обслуживание, когда ПО может быть недоступно или работать с ограничениями.

Минусы у облачного ПО тоже, к сожалению, есть.

Первый из них касается безопасности. Далеко не все компании морально готовы внедрять в свои приложения закрытое агентское ПО, которому необходим доступ в интернет, к тому же организация этого доступа из закрытых сегментов сети может вызвать большие затруднения.

Задача по настройке аутентификации и авторизации операторов облачной системы мониторинга с использованием корпоративных серверов LDAP/AD также не выглядит легко решаемой.

Еще один фактор: мониторинг приложений реализуется с помощью агентского ПО, которое внедряется в среды исполнения (Java/.NET и др.) и потенциально имеет доступ ко всем внутренним данным приложения. От потери клиентов по этой причине вендоры пытаются защищаться путём проведения периодических внешних аудитов, которые осуществляют авторитетные организации.

Еще одно узкое место – это необходимость наличия доступа в интернет. Для полноценной работы как самой системы мониторинга (отправка данных в облако), так и операторов системы необходим надёжный канал в интернет, работающий в режиме 24/7. Отсутствие доступа во «внешний мир» приведёт к остановке мониторинга даже внутренних приложений, что недопустимо во многих случаях.

Негативное влияние имеет и тот факт, что кастомизация поведения различных аспектов облачного ПО, как правило, выливается в создание своих расширений, что технически не так уж просто. Традиционные системы мониторинга основных вендоров могут предложить более широкие возможности для небольших доработок функционала.

И наконец приходится констатировать ограниченность функционала подобных продуктов для решения комплексных задач мониторинга корпоративных ИТ-систем.

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

• всесторонний анализ работоспособности бизнес-сервисов и инфраструктуры, учитывающий проблемы на всех уровнях (приложение, ИТ-инфраструктура, инженерное оборудование дата-центров и др.), что позволяет качественно выполнять аналитику и решать вопросы приоритизации возникающих инцидентов;
• наличие единой точки интеграции с системами оповещения и управления инцидентами;
• наличие единого долговременного хранилища данных для расчёта SLA, формирования отчётности, Capacity Management;
• эффективное взаимодействие с базами данных конфигурационных элементов (постановка на мониторинг, ресурсно-сервисные модели, анализ влияний, оркестрация);
• наличие основы для создания центра компетенции (автоматическое обогащение событий мониторинга инструкциями по устранению проблем, формируемыми исходя из опыта прошлых аварий и т.д.), что потенциально позволяет снизить требования к квалификации операторов мониторинга/дежурной смены, а также уменьшает время обработки аварий.

К сожалению, ни один из существующих облачных продуктов по мониторингу пока в роли «зонтика» выступить не может. Возможности даже самых функциональных решений заканчиваются, в лучшем случае, на уровне виртуализации, проблемы сети, СХД, инженерного оборудования дата-центров и т.д. остаются за кадром.

Интеграция же облачного ПО мониторинга приложений с «зонтичными» системами, как правило, технически проблематична. Максимум, на что можно рассчитывать без создания полнофункциональных интеграционных пакетов, – это включение интерфейса облачной системы в единую консоль «зонтика» и трансляция событий, которые генерирует облачное ПО, в «зонтик».

Тем не менее возможность выбора – это априори неплохо, поэтому если мы увидим, что для решения задачи компании больше всего подходит именно облачная система, мы с удовольствием поможем ее внедрить. Для компаний, которым не подходит облачное ПО мониторинга, мы можем предложить вариант с традиционным ПО, предоставляемым клиенту по облачной схеме. Это может оказаться оптимальным решением, так как в подобном случае снимается большинство вопросов с безопасностью и остаётся доступным функционал «зонтичных» систем мониторинга.