Этот термин имеет достаточно широкий смысл. В данном случае он предполагает мониторинг и анализ реального трафика, действий настоящих пользователей, словом, реальной среды, где происходит все самое интересное для владельца приложения, разработчика и администратора. CEM является компонентом APM-модели (Application Performance Management Model), предложенной аналитической компанией Forrester. По классификации Forrester, это Real User Performance Monitoring (см. рис. 1).
Рис. 1. APM-модель Forrester
Предлагаем вместе рассмотреть разновидности таких решений, их преимущества и ограничения, которые они накладывают. Сразу же оговоримся, что существуют также средства мониторинга, подразумевающие модификацию исходного кода веб-приложения (или установку агента на веб-сервер), отправляющие статистику в подсистему аналитики (на рынке наиболее распространены облачные решения). По замыслу вендоров они могут относиться к классу CEM, однако мы не будем рассматривать их в статье.
Решаемые задачи
Бизнес-приложение – это комплекс программных средств, которые поддерживают определённый бизнес-процесс компании (CRM, ERP и т.п.). Чаще всего в этот комплекс входят веб-сервер, сервер приложений и сервер базы данных, которые определенным образом взаимодействуют между собой. Задача мониторинга пользовательских транзакций заключается в поиске узких мест приложения и диагностике проблем при ситуациях, когда метрики его прикладных составляющих в норме, но пользователи жалуются на его производительность или уровень доступности. Спектр заинтересованных в таких системах лиц достаточно широк: это и ИТ (контроль работы, обнаружение проблем, возможность восстановить сессию пользователя), и бизнес (результативность работы бизнес-подразделения, оптимальность процессов и логики работы систем). Системы CEM предлагают следующую концепцию мониторинга: наличие или отсутствие проблем определяется производительностью приложения для каждого пользователя в отдельности (что, кстати, вовсе не отменяет контроль отдельно взятых компонент) в разрезе времени выполнения транзакции и реакции приложения. Логика информационного обмена между пользователем и приложением в общем случае представлена на рис. 2.
Рис. 2. Логика информационного обмена между пользователем и приложением
Для случаев, когда необходимо анализировать HTTP/HTTPS-трафик между пользователем и front-end’ом приложения, на промежуточном маршрутизаторе настраивается зеркалирование трафика на сервер с CEM-приложением подобно тому, как изображено на рис. 3.
Рис. 3. Принципиальная схема зеркалирования трафика на CEM-приложение
В свою очередь сервер CEM может быть расположен как на физической, так и на виртуальной инфраструктуре. Абсолютное большинство CEM-систем поставляется в виде appliance, т.е. решения, полностью готового к имплементации. Для зеркалирования трафика на физический сервер чаще всего используется «железный» коммутатор, в виртуальной среде – соответственно, виртуальный. По опыту можем сказать, что последний вариант наиболее распространен в среде VMware, да и веб-серверы бизнес-приложений тоже, как правило, виртуализированы. На рис. 4 схематично изображен механизм зеркалирования трафика на виртуальный и физический серверы CEM, когда в рамках виртуального свитча (vDS) включен смешанный режим (Promiscuous Mode). Его включение позволяет перенаправить на сервер CEM трафик со всех порт-групп, определенных на этом свитче.
Рис. 4. Схема зеркалирования трафика в среде виртуализации для физического и виртуального размещений CEM-приложения
Нельзя не упомянуть о том, что средства CEM могут масштабироваться в соответствии с требованиями компании. На рис. 5 приведены CEM-приложения, состоящие из нескольких компонент (в данном случае анализатор и коллектор), которые могут быть расширены. При значительном объеме поступающего трафика (или его приеме с различных веб-серверов) коллектор выносится на отдельный сервер.
Рис. 5. Пример масштабирования CEM-приложения
Выше мы говорили только о решениях по захвату HTTP/HTTPS-трафика, однако стоит упомянуть и о технологиях AANPM – Application-Aware Network Performance Manage-ment. Это ориентированные на приложения средства сетевого мониторинга, которые являются продвинутой версией CEM-решений и могут захватывать не только HTTP/HTTPS-трафик, но и, например, запросы к БД или VoIP-пакеты (что немаловажно, с дальнейшим воспроизведением разговора).
Визуализация результата
Теперь, когда с механикой приема данных все более-менее понятно, перейдем к описанию логики работы подобных решений. Для снижения паразитной нагрузки на приложение мониторинга перед началом его использования обязательно задаются адреса источника и получателя трафика, а также сетевой порт. После начала приема трафика можно приступать к созданию dashboard’ов. В этом плане всё ограничивается только требованиями к контролируемым метрикам, т.к. для построения dashboard’ов можно обращаться к разнообразной статистике (тип браузера, местоположение пользователя, ID сессии пользователя, количество ошибок при загрузке и многое другое, что характеризует сессию). Пример такого dashboard’а представлен на рис. 6.
Рис. 6. Пример dashboard’а CEM-приложения
Также существует возможность задавать заранее определенный сценарий пользовательской активности, т.е. создавать так называемый «стакан» (см. рис. 7). По нему мы можем определить, например, какое количество пользователей положило заказ в корзину и дошло до этапа его оплаты, какова сумма покупки, почему клиент покинул страницу перед оплатой и т.п.
Рис. 7. Пример визуализации сценария пользовательской активности
Таким образом, можно заглянуть в одну из сессий и пошагово увидеть пользовательские действия (см. рис. 8).
Рис. 8. Табличное пошаговое представление активности пользователя
Затем мы можем определить, на каком именно этапе у пользователя возникла, например, ошибка 500, когда он покинул сценарий и не стал заказывать товар или услугу (рис. 9).
Рис. 9. Детализированное представление пользовательского действия
Вернемся к AANPM. На рис. 10 в центральном фрейме можно увидеть примеры поддерживаемых типов трафика, в частности, приведен проблемный запрос в БД Oracle, который в итоге является причиной замедления работы всего бизнес-приложения. Таким образом, CEM можно назвать «кирпичиком», который в числе прочих закладывает крепкий фундамент теплых отношений конечного пользователя и ИТ. Среди таких «кирпичиков» решения:
- Real User Monitor, HP
- AppVisibility Manager, BMC Software
- Application Delivery Analy-sis, CA
- Dynatrace User Experience Management, Compuware
- nGenius Performance Mana-ger, NetScout
- Visual TruView, Fluke Net-works
- SteelCentral, Riverbed Tech-nology
- Real User Experience Insight, Oracle
Рис. 10. Пример интерфейса AANPM-приложения
Ключевыми отличиями этих продуктов являются наличие набора поддерживаемых протоколов для анализа, а также поддержка специфических приложений. По первому критерию считаем нужным выделить AANPM-решение Visual TruView, которое, помимо обычных HTTP/HTTPS, позволяет анализировать протоколы IP-телефонии, потокового видео, SMTP, SMB и др. А решение Real User Experience Insight от Oracle позволяет создавать специальные dashboard’ы, учитывающие логику работы таких специфичных бизнес-приложений, как Siebel, E-business Suite, Fusion, PeopleSoft.
В заключение отметим, что CEM-решения являются логичным технологическим продолжением сетевых анализаторов трафика, в том числе NetFlow-анализаторов, которые в большинстве своем предоставляют возможность логировать трафик в хранилище и этим ограничиваются. CEM-системы в отличие от них имеют понятную визуализацию, которую с легкостью можно оптимизировать под требования компании. В подавляющем большинстве случаев они позволят решить множество ИТ- и бизнес-задач и в итоге дадут возможность разговаривать с пользователем на одном языке. Во многих спорных ситуациях именно благодаря этому инструменту можно будет четко понимать, где и что именно происходит, не тратить дополнительное время на диагностику проблемы, а приступать к ее решению, как только о ней стало известно.