Всем привет! Меня зовут Ольга Султанова, я главный инженер по тестированию в QA-отделе REG.RU. В статье я расскажу о том, как силами отдела мы сделали свой мониторинг страниц на основе Jmeter.  Однажды нашему отделу понадобился (или мы просто захотели) инструмент для постоянного измерения скорости загрузки страниц, с помощью которого можно узнавать о проблемах на сайте в режиме реального времени. Мониторить нужно было не весь сайт, а только отдельные страницы из списка критично важных для бизнеса. Попросили менеджеров собрать такой список и дополнительно достали перечень самых посещаемых страниц ― получилось примерно 50 урлов. В поисках инструмента мониторинга мы рассматривали варианты, которые уже используются в других командах, но ни один из них не подошёл. По крайней мере, нам так показалось. Причин много, но главная заключалась в том, что большинство инструментов собирают статистику, но не оповещают о проблемах в реальном времени. Плюс хотелось меньше зависеть от других команд, знать, что находится под капотом используемой системы, и доверять ей. Поэтому мы решили сделать свой сервис на базе Jmeter.  Почему Jmeter? Да только потому, что было больше опыта использования. Я проходила курс нагрузочного тестирования на нем и перенесла полученные знания в курс во внутренней Wiki, чтобы любой желающий мог на проверенных материалах быстро научиться пользоваться инструментом.  Над задачей работали в техническом чаптере (группа специалистов одного направления работы со сходными хард скиллами) отдела тестирования. Работу разделили на две части: Запуск мониторинга, которым занимались в рабочее время и закончили довольно быстро.  Написание сервиса для сбора и отображения статистики, которым мы занимались во внерабочее время. Нас набралось всего двое: коллега занимался фронтовой частью, а я ― бэком и получением данных из джиметра. На этом этапе мы неплохо прокачали скиллы, не особо связанные с тестированием. Мы добавили в сервис синхронизацию с MySQL. Для подключения к базе использовали JDBC Connection Configuration, а для отправки данных JDBC PostProcessor с запросом INSERT. В базу передавали текущее время, урл страницы, время загрузки и код ответа.  Нам было нужно не время ответа, а полное время загрузки страницы вместе со всеми элементами. Поэтому запросы в сценарий мы добавляли через плагин Webdriver Sampler, где обозначили элемент, который будет показывать, что страница полностью загрузилась: Для запуска сценария использовали Chromedriver Config. Чтобы не влиять на реальную скорость работы сайта, сценарий сделали без нагрузки. Для этого запросы отправляет только 1 юзер. Данные, полученные в результате запуска сценария, отправляются в БД. Вся сборка проходит примерно за 4 минуты, а запускаются каждые 10 минут по расписанию. Итого каждый запрос отправляется 6 раз в час, 144 раза в сутки. Для запуска используется GitLab CI Schedules. Чтобы сделать выборку из базы по последним результатам, написали js-скрипт. При появлении запросов, код ответа которых не 200 или время загрузки больше 10 секунд, отправляется алерт в дискорд-канал: Так мы можем максимально оперативно реагировать на проблемы на сайте.  Чтобы понимать, какие страницы отвечают медленнее других и требуют доработки, алертов было недостаточно и нам нужна была статистика. Для этого мы сделали веб-интерфейс (flask + vue), который рисует графики на основе данных из БД.  На основе данных из БД формируются 3 основные таблицы: топ медленных запросов:  среднее время ответа за неделю:  таблица с ошибками: В таблице есть данные за последнюю неделю и сортировка по столбцам. По ссылкам можно найти детальные отчёты по странице в виде графика, где можно выбрать промежуток времени:  Так как в мониторинг включены только избранные страницы, мы добавили возможность добавления новых. На отдельной странице можно оставить заявку на добавление урла в мониторинг и увидеть список всех отслеживаемых страниц:  Заявки на добавление отправляются в дискорд QA-отдела. Сервису уже два года. Время от времени мы актуализируем страницы, выпиливаем старые, добавляем новые. Статистику почти не смотрим, но оповещения о проблемах в дискорде очень выручают. Теперь мы отправляем их в общий канал для всей компании, а не только на отдел тестирования. При любых проблемах с доступностью сайта или определенных его страниц мы сразу в курсе и можем оперативно отреагировать, не дожидаясь пока проблему обнаружат клиенты.  Если честно, мы ожидали большего внимания к нашему сервису от других отделов. За время его жизни было всего два запроса на добавление урлов: от админов (большой список в основном технических урлов) и мастеров (нужно было поставить на мониторинг страницу подбора доменов). Помимо своей полезности по функциональности,  проект оказался еще и развивающим за счет работы с кучей различных инструментов: Jmeter, SQL, GitLab CI, Docker, Flask, Vue. Работа над таким Pet-проектом позволила тестировщикам немножко погрузиться в работу фронтендеров, бэкендеров, девопсов и в целом подтянуть свои скиллы. За время разработки мы пару раз обращались за консультацией к DevOPS-инженерам, но в целом хватило своих сил и помощи Гугла.А еще мы на практике убедились, что тестировать свой функционал ― совсем не то же самое, что тестировать код, написанный кем-то другим. Когда сам пишешь код, кажется, что удалось предусмотреть абсолютно всё. Но это ощущение проходит, когда коллега тестировщик возвращается с немалым количеством багов.