Или кот )

Может это пароль

может переносит клаву в рюкзаке включенную

это нагрузочный тест

такой маленький, а уже тестировщик)

Дико извиняюсь, зачищено)

Все привет! На днях задавал вопросы по поводу интеграции джиметра с инфлюксом и графаной. Локально поднял - все работает, все красиво. Но возник вопрос:
Имплементация с backend лисенером нужна ведь только для отладки скриптов?

Поговорил с нашим техлидом. У нас проект, на котором УЖЕ прикручена графана, и там уже есть какая-то статистика по нагрузке серверов и прочие дашборды/статистики/метрики, относящиеся к проекту. Т.е. там графики постоянные и живут всегда - картина более общая, в отличии от варианта с бекенд лисенером, когда метрики живут только во время прогона тестов.
Он предложил забить на вариацию с бекенд лисенером джиметра, и делать разметку тестов (например, добавлять в реквесты какую-нибудь метадату, типа  "meta_data": {"jmeter": true}, дабы потом можно было статистику с джиметра отфильтровать и смотреть непосредственно метрики джиметра.

Возник еще один вопрос: когда будут проводиться испытания сервера конечные, каким вариантом сбора статистики для написания отчета воспользоваться?

- собирать статистику из графаны в контексте варианта с бекенд лисенером (вариант, когда графики живут только во время выполнения нагрузочного теста)
- собирать статистику из графаны в контексте варианта метрик, прикрученных к проекту в целом (вариант, когда графики живут в графане всегда)
- собирать статистику из джиметровского simple data writer (jtl, csv) - но тут для отчета придется джиметром графики визуализировать видимо, что не очень красиво, кмк)

Сори за возможно глупый вопрос, просто не понимания, в какой ситуации что использовать

кажется тут есть какое то недопонимание
вы говорите про мониторинг нагрузочных метрик и про мониторинг аппаратных/бизнес ресурсов - это разные вещи и все должны собираться

метрики с бекенд листенера отправляются во время теста, но храниться должны какое то продолжительное время, чтобы к ним можно было обратиться когда захочется сравнить новые релизы

> (например, добавлять в реквесты какую-нибудь метадату, типа  "meta_data": {"jmeter": true}

костыль в вакууме

Метрики jmeter вообще в отдельную базу пишутся в influxdb (обычно её так и называют jmeter). И зачем их тогда фильтровать.
И это именно метрики jmeter, а не железа, те это времена откликов, ошибки, количество потоков и тд.

Я бы не отдельную базу а отдельный инфлакс сделал

Безопаснее так и Легче если что вынести на отдельную машинку

лучше иметь метрики джеметра и метрики проекта будут несколько отличаться

Всем спасибо за ответы! На всякий случай, резюмирую. Верно понял, что:

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

2. Бекенд лисенер таки применим к конечным нагрузочным тестам (я почему-то думал, что он только для отладки, типа будет есть ресурсы джиметра)

3. Статистику и метрики для написания отчета брать из дашбордов интеграции графана/инфлакс/джиметр с бекенд лисенером

Тогда вопрос, зачем нужен jtl - отчет джиметровский, он где применим?

Он нужен в тех случаях, если не можешь использовать бэкенд лисенер

Менее удобный способ писать логи

Кстати а если нагрузка будет подаваться (точно будет) из нескольких точек - как быть с графаной и метриками в ней?

подкрутить как-то еще нужно?

зачем jtl-ка:
1) точные таймстампы
2) почему у меня все запросы с ошибкой? ну урл не тот например
3) питонячья аналитика по сохраняемым значениям, которые слать не хочется, а иногда надо

Вдогонку ко вчерашнему обсуждению отключения listeners на гейзенбаге

Я всегда в jmeter тесте отключаю listener-ы  перед запуском в non-gui.  Помню, что ранее можно было бысто выесть всю память если не отключишь view results, к примеру. Но сейчас уже, похоже, это не актуально  - можно запускать тесты с включенными listeners  и это не будет влиять на производительность.  

Провел тест на jmeter 5.4.1  - две TreadGroup последовательно - одна без listerers, другая - со всеми доступными.  Потребление ресурсов практически не изменилось