Как можно быстро и бесплатно попробовать APM-решение с пользой для себя

Всем привет! Меня зовут Александр. Около пяти лет я занимаюсь внедрением проектов по мониторингу в части производительности приложений и участием в таких проектах, более 10 лет — мониторингом и автоматизацией в ИТ.
В статье я хочу описать, как быстро и без затрат познакомиться с решением «Ключ-Астром», особенно если у вас есть свободный вечер или хотя бы пара часов, а заодно решить какой-нибудь кейс или отловить ошибку.
Если у вас есть ваш тестовый сервер, тестовый сервер команды разработки, который можно немножко нагрузить, или вы счастливый человек и имеете время на собственный пет-проект — вы можете поставить его на мониторинг.
Понадобятся всего лишь немного времени (час-полтора) и сетевая связность по одному порту. Ну разве что еще рестарт того, что хотите мониторить.
В тематических чатах можно увидеть обсуждения о том, что решения Application Performance Monitoring (APM) без спеца из интегратора или инженера со стороны вендора сложны в освоении, внедрении, что обычный тестировщик, разработчик, инженер получит только еще одну систему с перегруженным интерфейсом и собственными метриками только этой системы.
Я более чем уверен, что у вас уже есть мониторинг, к которому вы привыкли. Тем не менее есть возможность попробовать увидеть немного больше при помощи средств APM.
Какие задачи можно решить прямо из коробки с минимальной дополнительной настройкой:
  1. При помощи «Сравнения» увидеть разницу между релизами.
  2. При помощи интерфейса проблем увидеть отклонения при обычной работе/тестировании.
  3. При помощи анализа времени отклика проанализировать узкие места в коде, приложении.
  4. Посмотреть тяжелые запросы в базу данных (БД), увидеть, какой запрос их порождает.
  5. Посмотреть пользовательский опыт, увидеть связку от действия пользователя до запросов в базы данных.
Приведу практический пример, как коллеги использовали продукт буквально за день, получая отчет и результат и удаляя агента к концу дня.
Данная система для каждого URL’а автоматически ведет свою базовую линию. Обучение происходит в течение двух часов. Разработчики устанавливали агента, подавали нагрузку, ждали два часа, завершали тесты, обновляли приложение, запускали тесты повторно — и смотрели в окно проблем, при необходимости — смотрели каждый запрос через инструмент «Сравнение».
Это я и попробую продемонстрировать. Коллеги собрали для меня приложение, сказав, что в одном методе была добавлена задержка. Я попробую показать, как при помощи данной системы и нагрузочного тестирования быстро выявить пострадавший запрос. Также для образца мне было выдано приложение без изменения кода. Его я и буду использовать как образец, чтобы система построила базовые линии.
Первое, с чего нужно начать, — с создания аккаунта: https://desk.ruscomtech.ru/registration
По почте подтверждаем ссылку. Выбираем тариф, он может быть любым. Переходим в кабинет и жмем кнопку «Начать мониторинг».
Пока создается среда, у нас есть пара минут. Посвятим их тому, чтобы узнать, что же мы получаем из коробки и как это работает. При установке единого агента на наш хост стартует несколько компонентов агента. Не будем углубляться в детали, но один из компонентов занимается тем, что внедряется в процессы/службы. Все зависит от технологии. Например, для IIS, NGINX внедряется модуль, для Java, .NET — добавляется код инструментальной диагностики. Условно можно сказать, что в процессе/службе появляется маленький агент, который работает в приложении.
Входим в пользовательский интерфейс. Видим много пунктов меню, в поиске можно набрать «Развернуть “Ключ-Астром”».
Выбираем операционную систему, в следующем меню жмем на кнопку «Cоздать токен».
После этого получаем заветную команду по загрузке и установке.
Отправляемся на хост и выполняем первую команду. На той же странице внизу есть список адресов, на которые пойдут данные мониторинга. Исходящее соединение инициализируется агентом, необходимо, чтобы ваш тестовый сервер мог достучаться на адреса по порту 443.
Пока скачивается скрипт установки, пара слов об архитектуре. Агент отправляет данные в кластер, открывать и перенаправлять порты не нужно. Конфигурация агента динамическая, ничего руками править не придется. Всю настройку мы осуществляем из интерфейса. Агент периодически делает запрос к кластеру на наличие изменений и применяет их в соответствии с настройками.
Надеюсь, добавление флага к команде wget «--no-check-certificate» вас не остановило.
Запускаем установщик с флагами:
Для себя я добавил хост-группу, если систем/серверов много — лучше добавить. Подробнее о том, зачем это нужно, можно посмотреть в обучении.
-set-infra-only=false --set-app-log-content-access=true --set-network-zone=default --set-host-group=120
В моем случае необходимо было повторно запустить службу, по всей видимости, мой тестовый хост за многими «проксями» и сетями не смог с первого раза достучаться до сервера.
Успешное подключение можно проверить по пункту меню «Хосты». Самый простой способ — через поиск найти хост.
Можно также проверить «Статус развертывания» — следующий пункт меню, куда кликали, чтобы скачать агент.
Отображение в инфографике хостов моего тестового сервера выглядит так:
Легко видеть, что «Ключ-Астром» уже недоволен ресурсами моего стенда в части диска.
Здесь же хочу отметить, что интерфейс системы динамический: если есть проблема — подсвечено красным, если проблема была, а сейчас стало лучше — будет окрашено зеленым.
Смело кликаю на хост и попадаю в инфографику хоста.
Мой сервер приложений найден — Apache Tomcat. В интерфейсе вижу предупреждение о том, что, если я хочу, чтобы инструментирование в этот процесс произошло, мне нужно перезапустить процесс.
Перезапуск сервера приложений:
После перезапуска мы сможем видеть дополнительные метрики Java на уровне процесса.
Также код обработки HTTP-запросов будет инструментирован и должны будут появиться сервисы.
В данном случае у меня опубликовано одно приложение, всем известный PetClinic.
Я перешел на страницу с сайтом. Также я вызвал админку томката
Результат можно видеть далее на скриншоте. У нас появились два сервиса.
При клике по верхней части инфографики можно видеть две записи:
  • Spring PetClinic
  • Tomcat Manager Application (/manager)
Таким образом, если я опубликую еще приложения, агент также инструментирует их и выделит в отдельный сервис. На паре скриншотов далее мы видим инфографику сервиса, а также отображение на ресурсно-сервисной модели, построенной автоматически.
В меню есть пункт «Сервисы», туда будут попадать все сущности.
Теперь можно с уверенностью подавать нагрузку на процесс. Система построит базовые линии только спустя два часа, при условии что будет достаточная нагрузка.
Исключительно для красоты я рекомендую выполнить простую операцию, которая добавит информации в систему о том, какая версия приложения загружена. Эта информация будет отображена на графиках. Буду отправлять эту информацию по API. Этот шаг не обязательный, и его можно пропустить. В скрипт нужно будет вписать ваше окружение (/e/*/ui) и ваш сгенерированный токен, чтобы получить информацию на графиках.
Эту информацию можно взять из URL’а браузера.
Нам потребуется создать токен. В меню самый последний пункт — «Токены доступа». Справа — «Сгенерировать токен доступа». Права — такие как на скриншоте. Сгенерировать токен доступа.
Также нам понадобится HOST-ID, его тоже можно посмотреть в адресной строке браузера.
Пример отображения события на графике:
Так как мы только установили агента, я сначала опубликую приложение-образец, подам нагрузку. После загружу приложение с дефектом, подам нагрузку. Загружаю приложение через админку томката, отправляю событие в систему при помощи скрипта send_normal.py.
В рассматриваемом примере у меня не так много запросов. Если бы в приложении было много URL’ов, каждый проверить вручную было бы очень тяжело. Конечно, многое можно выявить по результатам сборки приложения и автотестам. В моем примере не прошел бы тест, так как время замедления запроса значительное. Но в случае с мониторингом приложения, развернутого в k8s, мы бы видели деградацию (или улучшение) работы на реальных пользователях, если мы говорим о миллисекундах.
Далее на скриншоте видим нагрузку на наш сервис Spring PetClinic.
Удаляю приложение и загружаю новый релиз. Попутно выполняю скрипт send_slow.py. В то же время подаю нагрузку и смотрю на результат.
Для анализа замедления работы приложения или сервиса используются 50-й перцентиль — медиана и 90-й перцентиль. В то время как другие инструменты APM ориентированы на среднее время отклика, «Ключ-Астром» использует другой подход, который ориентирован на анализ всех данных, а не только тех, кто получил хорошее или среднее время отклика.
Ухудшение времени отклика для приложений и сервисов оценивается на основе скользящих пятиминутных интервалов. При оценке деградации работы приложения или сервиса в случае оценки 10 % самых медленных «Ключ-Астром» выбирает скользящие 15-минутные интервалы.
Для приложений эталонные значения производительности рассчитываются по четырем базисам и также на основе 5-минутных скользящих интервалов:
  • действие пользователя
  • геолокация
  • браузер
  • операционная система
В нашем случае у нас для каждого запроса построилась своя базовая линия.
Через пять минут после подачи нагрузки в проблемах появилось новое событие — P-22042.
На самом сервисе — сразу же определился проблемный запрос:
В самом сервисе видим вот такую картинку:
Система показывает основную причину деградации вызовов. Причиной является тот же сервис, поскольку наше приложение состоит из одного сервиса.
Система также проанализировала событие, которое мы отправляли. Но даже без отправки событий перезапуски, изменения конфигурации процесса/служб или в данном случае публикация приложения — всё анализируется искусственным интеллектом.
Можно выбрать «Анализ снижения времени отклика». Система подготовит отчет за нас.
На скриншоте далее видим, что время отклика тратится на стороне сервиса (Service execution).
Здесь может быть отображена как блокировка, wait-time, приостановка из-за работы GC, замедление выполнения может быть связано со взаимодействием с очередями или другими смежными системами. Отдельной строчкой идет замедление — из-за базы данных. В нашем случае мы видим добавление Active wait time — 1.33s.
В самом сервисе видим выкладку, где даны проценты и информация о базовой линии. В моем случае превышение на 16 тысяч процентов.
Отображение в системе — проблемный запрос отмечен красным.
Есть замечательная утилита, которую можно вызвать в сервисах, а именно инструмент «Сравнение», или Compare.
В моем случае я взял запрос /vets.xml — и сравниваю по времени отклика с тем, что было двумя часами ранее:
Также можно вызвать анализ времени отклика:
Далее видим, что сервис из-за проблемного запроса, находящегося в ожидании секунду, также отразился на работе и других запросов, но это влияние незначительное.
В причинах видим выполнение кода и Suspension — время приостановки из-за работы с GC.
А вот сравнение проблемного запроса. Видим быстрый отчет — время отклика ухудшилось на 1,33 секунды.
Иллюстрация работы утилиты сравнения на проблемном запросе.
Давайте вернем стенд в нормальное состояние.
В карточке проблемы — в «воспроизведении проблемы» — уже можно наблюдать появление «зеленой» информации.
А вот так выглядит сравнение нормального запроса с медленным.
Был разобран самый простой пример применения данной системы. Приложение достаточно простое. Хочу добавить, что можно инструментировать код через специальный механизм определения сервиса, условно — добавить выполнение отдельного метода класса, построить базовые линии для него. Все это сделать из интерфейса, не меняя кода вашего приложения. Затем так же подать нагрузку и воспользоваться инструментом сравнения.
Дополнительные скриншоты по регистрации