Нагрузочное тестирование, история автоматизации процесса

[atomheart]

Удивительно, что до сих пор никто не прокомментировал. Очень большую работу вы проделали, и достигли уже хороших результатов. Вы же наверняка видели как устроен LoadRunner? Чем-то Ваше решение напоминает Performance Center.
Как минимум появился интерес снова "потыкать" JMeter.
Но т.к. опыта работы с JMeter у меня мало, интересует такой вопрос:
Вы как-то собираете метрики утилизации HW во время тестов? Какие-нибудь сборщики интегрированы у вас (PerfMon, sar/top через ssh, Zabbix...)?
Интересно было бы узнать, как вы решили или будете решать такую задачу.

[v0devil]

Да конечно видел и много пользовался. Их идея разделения лоад раннера на несколько частей (VUgen, controller, analyzer) вдохновило меня поступить также. Это позволяет пилить отдельные части, не убивая другие.
Мониторинг у нас основан на Graphite, для которого мы собираем метрики при помощи набора скриптов из github.com/innogames/igcollect.
Для лоад тестов использовался долго Monitoring плагин из yandex-танка, который легко засылается на удалённую машину и собирает всё что нужно, собирая в удобночитаемый CSV (оч крутая штука).
Но сейчас всё равно ухожу в сторону парсинга данных из графита.

[atomheart]

Я так понимаю, что метрики собираются постоянно в Graphite, и потом Вы смотрите, какая утилизация была во время теста. Но не совсем понятно, у Вас в текущей реализации метрики утилизации HW, полученные из Graphite, как-то сливаются и отображаются в Analyzer? Можно ли получить среднюю утилизацию и утилизацию с шагом за период нагрузочного теста, чтобы можно было их так же сравнивать с прошлыми тестами, по аналогии с временами отклика?

[v0devil]

Да, вместе с файлом результатов самого jmeter собирается также похожий CSV-файл с результатами мониторинга для каждого теста. И эти результаты хранятся в БД их можно отрисовать или сравнить с предыдущими тестами:

Простой график сравнения:

[atomheart]

Отлично, это очень здорово) В основном именно отсутствие возможности автоматической синхронизации данных теста с данными утилизации меня отпугивало от применения JMeter. Спасибо!

[saw_tooth]

А PerfMon Metrics Collection Вы не пробовали?

ТСу:
Я делал подобную штуку, правда не в таких масштабах (не нужно было огромных нагрузок, все куда проще). Крутилось все на flask/sqlite, морда на vue. Люблю минимализм и отсутствие зависимостей( никакого там планировщика, или очереди задач, ровно как и отведенного сервиса БД) В плане работы было все просто: добавляешь jmx на морде, выставляешь настройки (если они есть типа урл/кол. юзеров и т.п), запускаешь. Python запускает jmeter, и читает stdout, кладет все в базу, ну и там vue уже все рисует. Для каждого из jmx были конфигурации (проект с измененными параметрами), что бы можно было быстро там включить stage/dev сервера. База что бы не разбухала после месяца архивировалась и создавалась новая (в целом дольше хранить исходники результатов не имело смысла).В общем как то так.

[atomheart]

Еще вопрос — есть ли у Вас (или может планируется) какое-то API, чтобы можно было выполнять хотя бы часть простых действий (запуск теста, например) из вне?

[kptvlr]

Подскажите пожалуйста, если я правильно понял, речь идёт о системе мониторинга нагрузочных тестов. Но для этих целей есть уже готовые решения, такие как база данных InfluxDB для хранения метрик и дашборд Grafana для их отображения. Так же можно использовать дашборд Chronograf для визуализации данных наряду с Grafana. На проекте где я проводил нагрузочные тесты я развернул инфраструктуру с JMeter и упомянутыми программными решениями. При запуске тестов в консольном режиме данные с метриками прилетали в InfluxDB с агентов установленных на тестируемых машинах (где были развернуты сервер приложения и сервер БД), а также с JMeter-а. Далее было достаточно удобно как мониторить в режиме реального времени, так и смотреть результаты сохранённых тестов.

[v0devil]

Речь идет о анализе результатов, сравнении результатов для различных тестов/проектов, построения красивеньких отчетов, хранении их, а так же (в случае моей компании) запуск тестов для разных проектов независимо друг от друга на общих серверах. Мониторинг -это как бонус, который можно использовать и до развить как альтернативу того, что вы описали (я кстати тоже по началу такую систему развернул, но когда ленивые девелоперы не хотели долго искать в графане и сравнивать графики от разных тестов, а хотели просто увидеть суммарный отчет и общий тренд — необходимо было делать эту вот штуку.)

[Ghool]

Очень здорово, спасибо