eng
Перехват трафика вызывает стойкие негативные ассоциации, но в некоторых случаях он может быть и полезным.
Решаемые задачи
Речь идет об относительно новой категории программного обеспечения по управлению производительностью бизнес-приложений – ПО класса Customer Experience Management (CEM). Этот термин имеет достаточно широкий смысл. В данном случае он предполагает мониторинг и анализ реального трафика, действий настоящих пользователей – словом, среды, где происходит все самое интересное для владельца приложения, разработчика и администратора. Предлагаем рассмотреть разновидности таких решений, их преимущества и ограничения, которые они накладывают. Сразу оговоримся, что существуют также средства мониторинга, подразумевающие модификацию исходного кода веб-приложения (или установку агента на веб-сервер), отправляющие статистику в подсистему аналитики (на рынке наиболее распространены облачные решения). По замыслу вендоров они могут относиться к классу CEM, однако мы не будем рассматривать их в статье.
Бизнес-приложение – это комплекс программных средств, которые поддерживают определенный бизнес-процесс компании (CRM, ERP и т.п.). Чаще всего в этот комплекс входят веб-сервер, сервер приложений и сервер базы данных, которые определенным образом взаимодействуют между собой. Задача мониторинга пользовательских транзакций заключается в поиске "узких" мест приложения и диагностике проблем при ситуациях, когда метрики его прикладных составляющих в норме, но пользователи жалуются на его производительность или уровень доступности. Спектр заинтересованных в таких системах лиц достаточно широк – это и ИТ (контроль работы, обнаружение проблем, возможность восстановить сессию пользователя), и бизнес (результативность работы бизнес-подразделения, оптимальность процессов и логики работы систем). Системы CEM предлагают следующую концепцию мониторинга: наличие или отсутствие проблем определяется производительностью приложения для каждого пользователя в отдельности (что, кстати, вовсе не отменяет контроль отдельно взятых компонент) в разрезе времени выполнения транзакции и реакции приложения. Логика информационного обмена между пользователем и приложением в общем случае представлена на рис.1.
Для случаев, когда необходимо анализировать HTTP/HTTPS-трафик между пользователем и фронт-эндом приложения, на промежуточном маршрутизаторе настраивается зеркалирование трафика на сервер с CEM-приложением подобно тому, как изображено на рис.2.
В свою очередь, сервер CEM может быть расположен как на физической, так и на виртуальной инфраструктуре. Абсолютное большинство CEM-систем поставляется в виде appliance, то есть решения, полностью готового к имплементации. Для зеркалирования трафика на физический сервер чаще всего используется "железный" коммутатор; в виртуальной среде, соответственно, виртуальный. По опыту можем сказать, что последний вариант наиболее распространен в среде VMware, да и веб-серверы бизнес-приложений тоже, как правило, виртуализированы. На рис.3 схематично изображен механизм зеркалирования трафика на виртуальный и физический серверы CEM, когда в рамках виртуального свитча (vDS) включен смешанный режим (Promiscuous Mode). Его включение позволяет перенаправить на сервер CEM трафик со всех порт-групп, определенных на этом свитче.
Нельзя не упомянуть о том, что средства CEM могут масштабироваться в соответствии с требованиями компании. На рис.4 приведены CEM-приложения, состоящие из нескольких компонент (в данном случае анализатор и коллектор), которые могут быть расширены. При значительном объеме поступающего трафика (или его приеме с различных веб-серверов) коллектор выносится на отдельный сервер.
Выше мы говорили только о решениях по захвату HTTP/HTTPS-трафика, однако стоит упомянуть и о технологиях AANPM – Application-Aware Network Performance Management. Это ориентированные на приложения средства сетевого мониторинга, которые являются продвинутой версией CEM-решений и могут захватывать не только HTTP/HTTPS-трафик, но и, например, запросы к БД или VoIP-пакеты (что немаловажно, с дальнейшим воспроизведением разговора).
Визуализация результата
Теперь, когда с механикой приема данных все более-менее понятно, перейдем к описанию логики работы подобных решений. Для снижения паразитной нагрузки на приложение мониторинга перед началом его использования обязательно задаются адреса источника и получателя трафика, а также сетевой порт. После начала приема трафика можно приступать к созданию дашбордов. В этом плане все ограничивается только требованиями к контролируемым метрикам, так как для построения дашбордов можно обращаться к разнообразной статистике (тип браузера, местоположение пользователя, ID сессии пользователя, количество ошибок при загрузке и многое другое, что характеризует сессию). Также существует возможность задавать заранее определенный сценарий пользовательской активности, то есть создавать так называемый "стакан" [1]. По нему мы можем определить, например, какое количество пользователей положило заказ в корзину и дошло до этапа его оплаты, какова сумма покупки, почему клиент покинул страницу перед оплатой и т.п. Таким образом, можно заглянуть в одну из сессий и пошагово увидеть пользовательские действия. Затем мы можем определить, на каком именно этапе у пользователя возникла ошибка, когда он покинул сценарий и не стал заказывать товар или услугу. Таким образом, CEM можно назвать "кирпичиком", который в числе прочих закладывает крепкий фундамент теплых отношений конечного пользователя и ИТ.
В заключение отметим, что CEM-решения представляют собой логичное технологическое продолжение сетевых анализаторов трафика, в том числе NetFlow-анализаторов, которые в большинстве своем предоставляют возможность логировать трафик в хранилище и этим ограничиваются. CEM-системы, в отличие от них, имеют понятную визуализацию, которую с легкостью можно оптимизировать под требования компании. В подавляющем большинстве случаев они позволят решить множество ИТ- и бизнес-задач и в итоге позволят разговаривать с пользователем на одном языке. Во многих спорных ситуациях именно благодаря этому инструменту можно будет четко понимать, где и что именно происходит, не тратить дополнительное время на диагностику проблемы, а приступать к ее решению, как только о ней стало известно.
ЛИТЕРАТУРА
1.Касимов А. Перехват трафика с человеческим лицом. – Jet Info, 2014, №12 [Электронный ресурс]:URL http://www.jetinfo.ru/jetinfo_arhiv/2014.
Речь идет об относительно новой категории программного обеспечения по управлению производительностью бизнес-приложений – ПО класса Customer Experience Management (CEM). Этот термин имеет достаточно широкий смысл. В данном случае он предполагает мониторинг и анализ реального трафика, действий настоящих пользователей – словом, среды, где происходит все самое интересное для владельца приложения, разработчика и администратора. Предлагаем рассмотреть разновидности таких решений, их преимущества и ограничения, которые они накладывают. Сразу оговоримся, что существуют также средства мониторинга, подразумевающие модификацию исходного кода веб-приложения (или установку агента на веб-сервер), отправляющие статистику в подсистему аналитики (на рынке наиболее распространены облачные решения). По замыслу вендоров они могут относиться к классу CEM, однако мы не будем рассматривать их в статье.
Бизнес-приложение – это комплекс программных средств, которые поддерживают определенный бизнес-процесс компании (CRM, ERP и т.п.). Чаще всего в этот комплекс входят веб-сервер, сервер приложений и сервер базы данных, которые определенным образом взаимодействуют между собой. Задача мониторинга пользовательских транзакций заключается в поиске "узких" мест приложения и диагностике проблем при ситуациях, когда метрики его прикладных составляющих в норме, но пользователи жалуются на его производительность или уровень доступности. Спектр заинтересованных в таких системах лиц достаточно широк – это и ИТ (контроль работы, обнаружение проблем, возможность восстановить сессию пользователя), и бизнес (результативность работы бизнес-подразделения, оптимальность процессов и логики работы систем). Системы CEM предлагают следующую концепцию мониторинга: наличие или отсутствие проблем определяется производительностью приложения для каждого пользователя в отдельности (что, кстати, вовсе не отменяет контроль отдельно взятых компонент) в разрезе времени выполнения транзакции и реакции приложения. Логика информационного обмена между пользователем и приложением в общем случае представлена на рис.1.
Для случаев, когда необходимо анализировать HTTP/HTTPS-трафик между пользователем и фронт-эндом приложения, на промежуточном маршрутизаторе настраивается зеркалирование трафика на сервер с CEM-приложением подобно тому, как изображено на рис.2.
В свою очередь, сервер CEM может быть расположен как на физической, так и на виртуальной инфраструктуре. Абсолютное большинство CEM-систем поставляется в виде appliance, то есть решения, полностью готового к имплементации. Для зеркалирования трафика на физический сервер чаще всего используется "железный" коммутатор; в виртуальной среде, соответственно, виртуальный. По опыту можем сказать, что последний вариант наиболее распространен в среде VMware, да и веб-серверы бизнес-приложений тоже, как правило, виртуализированы. На рис.3 схематично изображен механизм зеркалирования трафика на виртуальный и физический серверы CEM, когда в рамках виртуального свитча (vDS) включен смешанный режим (Promiscuous Mode). Его включение позволяет перенаправить на сервер CEM трафик со всех порт-групп, определенных на этом свитче.
Нельзя не упомянуть о том, что средства CEM могут масштабироваться в соответствии с требованиями компании. На рис.4 приведены CEM-приложения, состоящие из нескольких компонент (в данном случае анализатор и коллектор), которые могут быть расширены. При значительном объеме поступающего трафика (или его приеме с различных веб-серверов) коллектор выносится на отдельный сервер.
Выше мы говорили только о решениях по захвату HTTP/HTTPS-трафика, однако стоит упомянуть и о технологиях AANPM – Application-Aware Network Performance Management. Это ориентированные на приложения средства сетевого мониторинга, которые являются продвинутой версией CEM-решений и могут захватывать не только HTTP/HTTPS-трафик, но и, например, запросы к БД или VoIP-пакеты (что немаловажно, с дальнейшим воспроизведением разговора).
Визуализация результата
Теперь, когда с механикой приема данных все более-менее понятно, перейдем к описанию логики работы подобных решений. Для снижения паразитной нагрузки на приложение мониторинга перед началом его использования обязательно задаются адреса источника и получателя трафика, а также сетевой порт. После начала приема трафика можно приступать к созданию дашбордов. В этом плане все ограничивается только требованиями к контролируемым метрикам, так как для построения дашбордов можно обращаться к разнообразной статистике (тип браузера, местоположение пользователя, ID сессии пользователя, количество ошибок при загрузке и многое другое, что характеризует сессию). Также существует возможность задавать заранее определенный сценарий пользовательской активности, то есть создавать так называемый "стакан" [1]. По нему мы можем определить, например, какое количество пользователей положило заказ в корзину и дошло до этапа его оплаты, какова сумма покупки, почему клиент покинул страницу перед оплатой и т.п. Таким образом, можно заглянуть в одну из сессий и пошагово увидеть пользовательские действия. Затем мы можем определить, на каком именно этапе у пользователя возникла ошибка, когда он покинул сценарий и не стал заказывать товар или услугу. Таким образом, CEM можно назвать "кирпичиком", который в числе прочих закладывает крепкий фундамент теплых отношений конечного пользователя и ИТ.
В заключение отметим, что CEM-решения представляют собой логичное технологическое продолжение сетевых анализаторов трафика, в том числе NetFlow-анализаторов, которые в большинстве своем предоставляют возможность логировать трафик в хранилище и этим ограничиваются. CEM-системы, в отличие от них, имеют понятную визуализацию, которую с легкостью можно оптимизировать под требования компании. В подавляющем большинстве случаев они позволят решить множество ИТ- и бизнес-задач и в итоге позволят разговаривать с пользователем на одном языке. Во многих спорных ситуациях именно благодаря этому инструменту можно будет четко понимать, где и что именно происходит, не тратить дополнительное время на диагностику проблемы, а приступать к ее решению, как только о ней стало известно.
ЛИТЕРАТУРА
1.Касимов А. Перехват трафика с человеческим лицом. – Jet Info, 2014, №12 [Электронный ресурс]:URL http://www.jetinfo.ru/jetinfo_arhiv/2014.
Отзывы читателей
