хехе злобный бот

https://jmeter-plugins.org/wiki/ParameterizedController/

Но, да, похоже, такую штуку нужно в базовой поставке

Приветствую, сорри за возможно легкий оффтоп, но есть вопрос ) какие типовые схемы мониторинга нагрузки приложений, живущих в кубере, а точнее нагрузки этих приложений на железо? Как бы с обычными виртуалками всё понятно - берем CPU, Memory, IO, Network - и это наша saturation метрика. Ну и ставим алерты, следящие, чтобы CPU или Memory не ползли к 100%. А в кубере у нас появляется еще один слой контейнеров (хоть и с квотами), причем кубер еще и managed (AWS EKS), и тут вот становится непонятно - мониторить контейнеры каким-нибудь cAdvisor? Мониторить ноды кубера? Мониторить и то и то? А если в кластере разные приложения будут? В общем, буду рад любым пинкам в правильном направлении )

Мониторить и то и то

https://medium.com/@janehojy/openshift-4-monitoring-exploring-grafana-part-i-46e93279571c
у нас так, взяли от бесплатного опершифта лучшее. может и на обычный кубер можно натянуть

но мониторить надо все уровни да

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

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

какой смысл мониторить какие то аппаратные ресурсы если за 2 секунды можно отскейлить

ресурсы имеют предел и деньги на скейл тоже

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

вопрос на миллион. приложение фактически стейтфул (имеет нормальный такой in-memory cache), нормально не масштабируется, кубер на данный момент вкатили ради относительно простых zero-downtime апгрейдов и улучшением ситуации с конфигурацией нод (до этого были долгоживующие виртуалки и паппет)

Это не то, нам с Семёном не параметры подменять надо а параметризовать путь к тест-фрагментам, вызываемым через include-контроллер.

Как я понимаю, тут проблема в том, что эти пути проверяются при запуске жметра и читаются просто как строки, так что функции/проперти там не вписать.

Что меня ещё больше удивило- переменные окружения (операционки) там тоже не удалось использовать

спасибо, особенно за идею посмотреть что поднавернули в энтерпрайзном кубере )

Vrt в последних версиях не влияет (отключается при запуске без гуи)

А debug sampler влияет

о. спасибо а то я по незнанию внутрь дебага сунул некий функционал

это опенсорсная история

А, т.е. хотите в зависимости от параметра инклудить то одно, то другое?

Вообще говоря, текущая реализация в JM такая, что include дублирует (клонирует) содержимое.
Поэтому workaround это сделать switch(…) и вызывать его через parameterized controller

Хотим сделать один скрипт-раннер, который в зависимости от переданных проперти вызывает разные jmx-файлы с тест-фрагментами

Т.е. вам kotlin dsl нужен? ;)