Нагружаем и отдыхаем: load testing без стресса ч.2 — автоматизация

Доброе утро)
Прекрасный вопрос)

Для остановки теста мы используем пороги (thresholds) с условиями реакции на их пересечение.
Вот тут документация поясняющая работу порогов - https://grafana.com/docs/k6/latest/using-k6/thresholds/

Пример:

thresholds: {iteration_duration: [{ threshold: "p(95)<10000", abortOnFail: true }]} 

В такой конфигурации k6 для каждой итерации (то есть совокупности выполнения всех шагов скрипта) будет проверять что время выполнения всего скрипта меньше 10сек
и если больше или равно, то скрип остановится с exitCode = 99 (Пересечен порог)

Про коды я узнала из этого issue =)

Смысл в том, что мы объявляем условие, нарушение которого приведет к остановке скрипта, если указан abortOnFail=true, или если его нет, то пересечение порога отметится в метриках результата без прерывания.
А условия могут быть любыми, как со стандартными метриками(длительность итерации или запроса), так и кастомные проверки с условиями (checks, например).

Представим, что в скрипте задана проверка кода ответа запроса, код = 200

check(res, {
    'status is 200': (r) => r.status == 200,
  });

Для замера допустимо чтобы не более 10% запросов упали с кодом отличным от 200.
Если ошибок больше - то скрипт должен быть прерван.
Тогда порог будет выглядеть вот так:

thresholds: {checks: [{ threshold: "rate>0.9", abortOnFail: true }]} 

Добрый день)

Вы правы, в перспективе установившегося процесса можно отказаться от необходимости сборки образа k6, в пользу бинарника.

На момент когда каждую неделю я писала новые скрипты, подключала бибилиотеки, игралась с версиями ... мне так было удобнее)
Для локального запуска (на моем маке) у меня была команда подготовки билда с нужными либами, моя коллега на винде могла собрать себе билд, подготовить и проверить новые скрипты нагрузки, а в это время CI/CD гонял как регресс, так и новые скрипты с зависимостями.

Спасибо, что обратили внимание) Думаю, что сейчас можно пересмотреть подход и оценить что будет быстрее и легче: хранить несколько бинарников или оставить сборку в pipeline.


Про отчет я не совсем вас поняла.
Сообщение в бот и ссылки высылаются в конце замеров. Это было важно, потому что в ссылки к Grafana подставляются время старта и окончания замеров, gitlab артефакты так же появляются, когда билд замеров выполнен.

Возможно вас смутил пример из документации k6, но от дополнительного спама в начале замеров можно отказаться.

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

Для настройки интеграции необходимо установить переменные (у нас они в gitllab переменных проекта прописаны), и настроить Grafana на работу с Prometheus. Более мы ничего не усложняли.
Далее можно взять пример нашего борда и настроить его под себя.