Привет, Хабр! На связи Денис Киров, руководитель отдела тестирования компании «Цифровые Технологии» — мы отвечаем за качество продуктов Единой информационной системы жилищного строительства (ЕИСЖС), занимаемся функциональным тестированием, автоматизацией функционального тестирования и тестированием производительности информационных систем.
В современном конкурентном мире компании, разрабатывающие программные продукты, активно работают над повышением качества и стабильности работы информационных систем. Эта статья посвящена одному из вариантов контроля качества производительности информационных систем — мониторингу APDEX. Его основная цель — получение реальных данных о быстродействии системы глазами пользователя. Мы расскажем о методологии внедрения механизма мониторинга для портала наш.дом.рф.
Что такое APDEX?
Apdex (Application Performance Index) — индекс производительности приложений. Это открытый международный стандарт, разработанный с целью формирования объективной оценки показателей производительности корпоративных информационных систем. Индекс используется для измерения пользовательской удовлетворенности работой системы. Формулу расчета и интерпретацию результата мы распишем в другой части статьи.
Вводные
Однажды я наткнулся на статью на Хабре, в которой описывался мониторинг операций в 1С и дальнейшая интерпретация результатов при помощи расчета индекса APDEX. Замеры операций производились «из коробки» 1С. На этой основе возникла идея, сделать что-то подобное и для продуктов ДОМ.РФ силами отдела тестирования.
Задачу сформулировали так: настроить мониторинг производительности системы, чтобы можно было оценить текущее состояние и посмотреть, что было раньше. И чтобы это было удобно, доступно и понятно. Мониторить нужно два контура: препрод и прод.
Профиты, которые мы хотим получить:
Дополнительная метрика, которую можно анализировать и использовать в SLA, а также для отчетов бизнесу и руководству;
Возможность отслеживать теоретическую деградацию производительности в режиме 24/7, искать корреляции с поставками изменений на стенд или инфраструктурой;
Дополнение к эксплуатационному мониторингу недоступности модулей.
План работ:
Продумать технологический стек реализации задачи, понять и спроектировать процесс;
Проработать, что мы будем мониторить и согласовать выбранные метрики и показатели;
Запустить пилотный проект и отладить процесс.
Варианты реализации:
Мониторинг на основе логов из ELK. У нас реализовано единое хранилище логов при помощи ELK Stack, работающее по схеме, изображенной на рисунке 1.
![](https://habrastorage.org/getpro/habr/upload_files/9f7/79d/f75/9f779df756ddb6546090f4dda616e30b.png)
Рисунок 1. Единое хранилище логов
Этот вариант показался очень интересным, но возникло несколько нюансов.
Первая проблема: логирование под задачу необходимо дорабатывать, а сделать это самостоятельно показалось невозможным, так как доступа к настройке продуктового Logstash у сотрудников отдела тестирования нет, пришлось бы привлекать смежные отделы, а для пилотного проекта это делать не хотелось.
Вторая проблема: на препрод-контуре не всегда есть пользователи, поэтому пришлось бы эмулировать нагрузку на систему, чтобы не было пробелов в мониторинге.
Ввиду этого вариант мы положили в пул задач «to be» и реализуем в будущем.
Анализ по “Яндекс.Метрике” и аналитике от Гугл. Вариант похож на первый и обладает схожими проблемами, например, отсутствием подключенных метрик на препрод-контуре, поэтому такое решение посчитали нецелесообразным.
Реализация «робота», который будет делать замеры с определенной интенсивностью по пользовательским сценариям. Такое решение показалось самым быстрореализуемым и интересным, каких-либо трудностей и нюансов мы не увидели, поэтому решили пойти по этому пути.
Проектирование технологического стека
Мы решили максимально переиспользовать то, что у нас есть и применяется для задач АФТ и нагрузочного тестирования.
Поскольку мы хотели измерять производительность «глазами пользователя», то было принято решение взаимодействовать с продуктом через UI-интерфейс (браузер). Полученные замеры необходимо где-то хранить, для этого отлично подходит time series DB - Influx, у нас она используется для хранения инфраструктурных метрик мониторинга, а также результатов нагрузочных тестов (так как Jmeter "из коробки" хорошо дружит с InfluxDB), а хотелось все хранить в одном месте.
Чтобы запускать роботов изолированно друг от друга в docker-контейнерах и легко масштабировать их количество, было принято решение использовать Selenoid. А для визуализации данных и построения аналитического дашборда — всем известный и очень удобный инструмент Grafana.
В итоге получился следующий технологический стек:
Фреймворк с роботом для замеров на Java 11 + TestNG + Selenide
Selenoid — для контейнерезированного запуска роботов
Хранилище данных — InfluxDB
Telegraf коллекторы на ВМ с продуктом
Grafana — для визуализации данных и дашбордов
Схема технологического стека изображена на рисунке 2.
![](https://habrastorage.org/getpro/habr/upload_files/b45/a69/300/b45a693007dc71d155eb60dd52d0e94d.png)
Рисунок 2. Технологический стек мониторинга
Проработка метрик мониторинга и согласование
После того, как технологический стек реализации был определен, все настроено и ядро фреймворка написано, нас ожидал следующий пункт — выбор метрик мониторинга, их согласование и проработка методики расчета индекса APDEX и его корректной интерпретации.
Первое, что мы сделали — описали базовую методику на внутрикорпоративном Confluence (рисунок 3).
![](https://habrastorage.org/getpro/habr/upload_files/33c/260/957/33c260957444d1ab992d7e46feaa6d2d.png)
Рисунок 3. Описание методики
Формула расчета индекса была взята стандартная:
![](https://habrastorage.org/getpro/habr/upload_files/8df/0d2/a1d/8df0d2a1dacbd44ee1d13f1a836e47dd.png)
Интерпретация полученных результатов также стандартная:
![](https://habrastorage.org/getpro/habr/upload_files/d82/ac3/64d/d82ac364d6500c81dc3d14b27e5a0e8f.png)
Пояснения по формуле:
Кол-во операций в зоне “довольны” — это то время выполнения, при котором пользователь думает “О, все летает, классный сервис”;
Кол-во операций в зоне “удовлетворены” — это то время выполнения, при котором пользователь думает “Сервис, конечно, не летает, но в целом пойдет”;
Все, что дольше, чем зона “удовлетворены” — потенциальный негатив пользователя по производительности продукта, отказы и т.д.
После того, как мы определились с методикой, начали составление метрик мониторинга для портала наш.дом.рф, а также описали все на Confluence (рисунок 4) и пошли согласовывать метрики с проектным менеджером.
![](https://habrastorage.org/getpro/habr/upload_files/70e/30c/bbd/70e30cbbdff5a1fa9ae56c97fa48a256.png)
Рисунок 4. Согласованные операции для мониторинга продукта
Чтобы приоритизировать пользовательские операции, мы пошли на сервис “Яндекс.Метрика” и проанализировали статистику в разрезе месяца. Чем чаще выполняется операция, тем выше у нее приоритет.
Также мы определили целевое время выполнения операции (зона “довольны” при расчете индекса) и максимально допустимое время выполнения (зона “удовлетворены”).
Реализация мониторинга и запуск пилотного проекта
После реализации сценариев и отладки мы выбрали интервал запуска — 1 раз в 10 минут, закинули в cron запуск робота и стали собирать первую статистику.
Пока статистика накапливалась в хранилище данных, мы стали собирать аналитический дашборд, чтобы все полученные данные структурировать и обработать.
Пример полученного дашборда на рисунке 5:
![](https://habrastorage.org/getpro/habr/upload_files/c54/5b4/7bb/c545b47bb232bdadaedf38e949a320d9.png)
Рисунок 5. Пример собранного дашборда
Здесь первый элемент — таблица с основными данными:
Название операции
Приоритет
Т(с) - согласованное граничное максимальное время из интервала “довольны”
N - общее кол-во операций за выбранный временной диапазон
NS - кол-во операций из зоны “довольны”
NT - кол-во операций из зоны “удовлетворены”
NB - кол-во операций из зоны “недопустимо”
![](https://habrastorage.org/getpro/habr/upload_files/bf5/5f1/7b9/bf55f17b9e6a3d44f64a309a31f3a74a.png)
Рисунок 6. Общая таблица с результатами
На остальных двух элементах выводится количественный расчет индекса и оценка показателя, в соответствии с методикой (рисунок 7).
![](https://habrastorage.org/getpro/habr/upload_files/a19/6e9/392/a196e9392624ed576f16068c1a567863.png)
Рисунок 7. Расчет индекса и оценка
Выводятся данные при помощи запроса к БД InfluxDB (рисунок 8). Выборка данных ограничивается выбранным временным диапазоном в Grafana.
![](https://habrastorage.org/getpro/habr/upload_files/044/4ad/1ce/0444ad1cef78278ccaf2cf4d53991321.png)
Рисунок 8. Запрос для вывода информации в таблицу
Сам расчет индекса происходит также в Grafana на лету за выбранный временной интервал по формуле (рисунок 9).
![](https://habrastorage.org/getpro/habr/upload_files/a89/192/f76/a89192f7692360ecb6522e64e080046f.png)
Рисунок 9. Расчет индекса APDEX в Grafana
Визуализация оценки полученного результата реализована при помощи стандартных средств инструмента Grafana (рисунок 10)
![](https://habrastorage.org/getpro/habr/upload_files/6e1/43c/7dd/6e143c7dd3f669428dfb04602b675dba.png)
Рисунок 10. Визуализация оценки
Внизу дашборда выведен график, на котором можно посмотреть результаты замеров по каждому из кейсов, что полезно при падении индекса и поиске причин и корреляций (рисунок 11).
![](https://habrastorage.org/getpro/habr/upload_files/5da/08b/14c/5da08b14c25a91041c8202bb174918f3.png)
Рисунок 11. Результаты замеров
Чаще всего при анализе всплесков мы ищем корреляции с повышенной утилизацией инфраструктуры, которую мы также поставили на мониторинг (рисунок 12).
![](https://habrastorage.org/getpro/habr/upload_files/9ba/c0c/b50/9bac0cb50293ce55badf36ee72a73e90.png)
Рисунок 12. Утилизация ресурсов, выделенных docker-контейнерам приложения
Также при помощи стандартного Alert Manager в Grafana мы настроили уведомления о падении индекса APDEX (за интервал 24 часа) ниже определенного значения в мессенджер Telegram (рисунок 13).
![](https://habrastorage.org/getpro/habr/upload_files/d40/e2d/34d/d40e2d34ddf27b72fcbbc339a218ea7b.png)
Рисунок 13. Уведомления о падении значения индекса в Telegram
И при отсутствии данных при замере также срабатывает алерт с префиксом [No Data] (рисунок 14).
![](https://habrastorage.org/getpro/habr/upload_files/32f/f2d/ee2/32ff2dee2094950fc960e84201e82050.png)
Рисунок 14. Уведомление об отсутствии данных по замеру
Также в случае отсутствия данных робот присылает скриншот экрана, что позволяет идентифицировать проблему (рисунок 15).
![](https://habrastorage.org/getpro/habr/upload_files/8ff/480/afb/8ff480afbdda6e727966225e1c7b005d.png)
Рисунок 15. Скриншот от робота при отсутствии данных по замеру
Основные проблемы, которые могут возникнуть при использовании индекса APDEX:
Некорректный выбор временного интервала, за который рассчитывается индекс APDEX. Например, при выборе небольшого временного интервала могут быть просадки по индексу, вызванные разовыми выбросами, которые могут быть связаны с различными работами и т.д., что не является критичным, поэтому при конфигурации отчета желательно выбирать временной интервал не менее 12 часов (при интенсивности замеров раз в 15 минут), чтобы индекс показал реалистичную картину;
Некорректный временной интервал расчета индекса, а также граничного значения для отправки алертов. Для настройки алертов по снижению индекса APDEX необходимо аккуратно подойти к выбору граничного значения и временного интервала, за который рассчитывается индекс, чтобы рассылка в эксплуатацию не превратилась в спам и сигнализировала только в случае реальных проблем;
Подготовка тестовых данных для мониторинга. Необходимо аккуратно подойти к подготовке тестовых данных для мониторинга и обеспечить «неприкосновенность» данных;
Отсутствие динамики и корректировок нормативных значений индекса. Мониторинг APDEX может быть настроен на ранних этапах реализации системы, и новая бизнес-логика может “утяжелить” какие-то операции. Необходимо допускать возможность корректировок нормативов индекса, Perfomance Engineer должен постараться проанализировать, как добавление нового тяжелого функционала может повлиять на мониторинг, и, основываясь на результатах проведенного нагрузочного тестирования, скорректировать с бизнесом нормативы, в случае, если оптимизация системы и увеличение ресурсов невозможна.
Вывод
Инструмент оказался достаточно полезным, а реализация его не сильно трудозатратной, поэтому этот пилотный проект мы посчитали успешным и планируем его развивать и расширять, а также можем порекомендовать попробовать внедрить такой мониторинг всем желающим.