Всегда используйте мониторинг конечных пользователей

Этой истории могло бы и не быть, если бы использовался мониторинг конечных пользователей, который просто показал бы справедливость жалоб пользователей Rap Genius. Собирать статистику ответов приложения – это одна сторона медали, и она показывает только половину истинной картины. И полагаться на синтетические транзакции тоже не стоит, они не покажут всего, что происходит.

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

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

Учитывайте разницу между продуктами APM, ориентированными на разработчика, и теми, которые рассчитаны на администраторов и бизнес.

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

Маленькие стартапы могут себе позволить совмещать разработку и администрирование, когда разработчики управляют и продуктивной средой. В больших компаниях и предприятиях эти функции разделены, имеют различную организационную структуру, и у этих подразделений разные цели и задачи. Эти различия учитываются производителями APM-систем – одни ориентируются на помощь разработчикам, другие на поддержку администраторов.

Существуют проблемы с производительностью, которые просто не могут быть обнаружены APM-решениями, ориентированными на разработчиков, поскольку их нельзя заметить с уровня приложений. История Rap Genius и Heroku весьма показательна в этом отношении. Rap Genius использовал инструменты мониторинга, фокусирующиеся на потребностях разработчиков и не собиравших данных по очереди в Ruby платформе Heroku. Это было слепое место для выбранного решения, его нельзя было заметить изнутри уровня наблюдения (Ruby).

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

Основные отличия продуктов APM для администраторов:

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

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

Ясно понимайте, что именно вы мониторите и измеряете

Давайте вернемся к упоминавшейся в начале истории о среднем времени отклика. У этого понятия есть много определений, в зависимости от того, что именно измеряется. Например:

• Вы наблюдаете tcp-ip пакеты и протоколы на сетевом интерфейсе и смотрите, когда запрос пришел на сервер и когда ушел ответ? Если да, то какой интерфейс вы наблюдаете? На файерволе? На web-сервере? Сервере приложений? Где начинается и заканчивается путь пакетов запроса и ответа?
• Вы следите за протоколами и запросами, поступающими на вход выполняемого процесса? Если да, то какого именно процесса? Наблюдаете ли Вы за всеми выполняемыми процессами, участвующими в обработке запросов конечного пользователя?
• У Вас настроен мониторинг запросов и ответов изнутри сервера приложений (например, JVM)? С каким событием Вы связываете начало запроса – когда Servlet начинает его обработку внутри Java машины?

Каждый из этих вариантов происходит в различных точках транзакционного потока и выдаст разные значения. У каждого свои уровни видимости происходящего и свои слепые зоны.

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

Команда ALG DevOps Team будет благодарна за Ваши ответы на следующие вопросы: