Привет, коллеги! Меня зовут Василь Хамидуллин, и я тестировщик в компании fuse8.

В одном из недавних проектов нам поручили провести нагрузочное тестирование закрытой платформы со сложной ролевой моделью и запутанной авторизацией под капотом (Next.js, middleware, вот это всё).

Мы написали базовый скрипт на k6, сымитировали действия пользователей, запустили тест в терминале. В конце прогона консоль выдала красивую зеленую сводку: http_req_failed: 0%. Сервер держит нагрузку, можно идти пить кофе и радовать бизнес, верно?

Но интуиция подсказала заглянуть в тело ответов. Оказалось, что скрипт успешно проходил авторизацию (получая 200 OK), а вот дальше сервер на каждый тяжелый запрос к данным отдавал 400 Bad Request из-за недостающих UUID в payload. Наш нагрузочный тест просто молотил пустые ошибки валидации, не создавая реальной нагрузки на базу данных. И за быстро бегущими строками консольного лога мы этого даже не заметили.

А когда мы всё-таки пробили авторизацию и пустили реальный трафик, итоговые цифры в терминале не дали нам ответа на главный вопрос: а в какую именно секунду сервер начал захлебываться? Стало понятно, что смотреть в голую консоль бесполезно. Нужен был нормальный визуальный пульт управления нагрузкой. Причем локальный, чтобы тестировать новые фичи прямо на рабочей машине, и желательно без согласования бюджетов на облачные Enterprise-решения.

В этой статье я расскажу, как эволюционировал наш подход к визуализации результатов тестирования в k6: от простых HTML-отчетов и экспериментов с нейронками до развертывания «тяжелой артиллерии» в виде связки InfluxDB + Grafana. Покажу, как настроить визуализацию в уже готовых скриптах. И главное: покажу, зачем вообще нужно смотреть на графики в реальном времени, даже если вы тестируете небольшой внутренний сервис.

Зачем вообще нужна визуализация для локальных тестов?

Кажется, что для внутренней админки, небольшого закрытого сервиса или проверки отдельной новой фичи достаточно простого консольного лога. Но именно графики позволяют поймать момент, когда 50 пользователей работают нормально, а на 51-м база данных встает из-за неоптимального джоина.

Визуализация позволяет отследить динамику: как коррелирует рост числа пользователей с увеличением времени отклика, где находятся узкие места и не «течет» ли память при долгой нагрузке. Графики превращают массив сырых данных в наглядную историю, которую легко анализировать инженеру и не стыдно презентовать команде разработки.

Почему мы говорим именно о локальном тестировании? Все описанные ниже способы визуализации я применял локально. Локальное нагрузочное тестирование — это мощный инструмент, который идеально подходит для небольших закрытых сервисов, внутренних API или тестирования отдельных новых фич, не требующих генерации колоссальной распределенной нагрузки. Локальный запуск экономит ресурсы, избавляет от необходимости поднимать сложную облачную инфраструктуру и дает разработчику или QA моментальный фидбек прямо на его рабочей машине.

Спойлер для самых нетерпеливых: В этой статье мы подробно разберем, как связать k6, InfluxDB и Grafana с нуля своими руками. Это важно, чтобы понимать, как данные перетекают из системы в систему.

Но если вам нужен результат «здесь и сейчас», в самом конце статьи я оставил ссылку на готовый Starter Kit. Это мой GitHub-репозиторий, который поднимает всю инфраструктуру, прокидывает порты и автоматически загружает настроенные дашборды всего одной командой docker-compose up -d. Никакой ручной настройки — скачали и сразу пошли тестировать. А пока давайте заглянем под капот!

Разберем 4 способа визуализации результатов тестирования в k6, которые я опробовал на практике. Для начала нам потребуется сам k6: на Windows его можно установить в PowerShell командой winget install k6 и проверить успешность через k6 version.

Эволюция визуализации в k6

Способ 1. Использование нейронок

Начнем с самого простого способа. Использование нейросетей — современный подход. Здесь вам поможет ваш прокачанный навык формулировки промтов. Но прежде чем скормить нейронке промт, необходимо получить данные о результате тестирования в удобном для чат-ботов формате. Идеально, если это будет JSON-файл (конечно, можно использовать и другой формат, например CSV). Инструментарий k6 позволяет без особых усилий с помощью специальной команды вывести результаты тестирования сразу в нужном нам формате. Предположим, у вас уже есть готовый скрипт для запуска. Для того, чтобы получить нужный нам файл достаточно запустить нагрузочный тест с помощью команды: 

k6 run --out json=results.json script.js (где script.js — название вашего скрипта)

Итоговый файл result.json ищем в папке проекта и его же скармливаем нейронкам.

В промте можно попросить ИИ проанализировать результаты, выделить узкие места и построить графики распределения времени отклика и RPS (Requests Per Second — количество запросов в секунду). Можно даже скормить результаты в формате CSV и попросить написать Python-скрипт (с использованием Pandas и Matplotlib), чтобы объединить на одном графике с двумя осями Y количество активных пользователей (VUs) и время отклика для поиска корреляций.

Вот некоторые примеры промтов:

«Проанализируй результаты нагрузочного теста k6, выдели узкие места и построй графики распределения времени отклика (Percentiles) и RPS.»

«Это данные моего Spike-теста в k6. Построй график, где по оси X — время теста, а по оси Y — время отклика (http_req_duration) и количество активных пользователей (VUs). Выдели зону, где был пик нагрузки.»

«Это результаты теста k6 в формате CSV. Напиши скрипт на Python (Pandas + Matplotlib), чтобы построить два графика: 1. Количество активных пользователей (VUs) во времени. 2. Время отклика (http_req_duration) во времени. Объедини их на одном рисунке с двумя осями Y, чтобы я видел корреляцию.»

Итоги:

Плюсы: Возможность глубокого, кастомного анализа «человеческим» языком и получения готового кода для уникальных графиков с любыми осями.

Минусы: Требует ручных действий (сохранить, скопировать, написать промпт, запустить внешний скрипт), данные анализируются постфактум.

Когда применять: Когда стандартных отчетов не хватает, нужно найти неочевидные зависимости в данных, автоматизировать поиск «бутылочных горлышек» или быстро сгенерировать аналитическую текстовую сводку по метрикам.

Способ 2. k6-reporter (HTML-отчет)

Использование встроенных репортеров — распространенная практика для автоматической генерации отчетов. Описываемый мною репортер генерирует один автономный HTML-файл, в котором собраны таблицы и сводная информация по итогам теста. Этот способ также можно использовать для уже готового скрипта. Для генерации отчета достаточно добавить в раздел импорта скрипта две строки:

import { htmlReport } from "https://raw.githubusercontent.com/benc-uk/k6-reporter/main/dist/bundle.js"; 

import { textSummary } from "https://jslib.k6.io/k6-summary/0.0.1/index.js";

А в конце скрипта вызвать соответствующую функцию:

После завершения тестирования в папке проекта появится готовый файл summary.html, который можно открыть для просмотра и анализа.

Если хочется больше подробностей,  добро пожаловать на страницу документации по k6-reporter от benc-uk.

Пример сгенерированного отчета:

Итоги:

Плюсы: Не нужно ничего поднимать и настраивать, достаточно просто добавить одну функцию в код скрипта.

Минусы: Отчет полностью статичен, так как формируется только после окончания теста. Отсутствие графиков.

Когда применять: Для быстрых проверок, когда вам нужно зафиксировать результат прогона и, например, прикрепить компактный файл-сводку к задаче в Jira или отправить коллеге.

Способ 3. Встроенный Web Dashboard (графики + HTML отчёт)

Если вам нужны метрики в реальном времени, а разворачивать отдельную инфраструктуру с базами данных некогда, используйте встроенный k6 Web Dashboard. Это официальный инструмент, который транслирует графики прямо в браузер (по умолчанию на http://127.0.0.1:5665) во время теста, а по завершении позволяет сохранить красивый HTML-отчёт.

Включается этот дашборд максимально просто — передачей пары параметров при старте вашего скрипта. Готовые команды для быстрого запуска под Windows, macOS и Linux подробно описаны в официальной документации k6 Web Dashboard.

Пример сгенерированного отчета:

Итоги:

Плюсы: Дает графики в реальном времени «из коробки» без необходимости разворачивать сторонние базы данных.

Минусы: Функционал графиков и дашбордов ограничен тем, что заложили создатели, кастомизация минимальна.

Когда применять: Идеально для наблюдения за тестом «в прямом эфире», когда не хочется возиться с Docker, но обычного статичного отчета в конце теста уже недостаточно.

Способ 4. Локальная связка k6 + InfluxDB + Grafana

Наверное, самый интересный способ визуализации результатов, но в то же время и самый трудоемкий. Для использования этой связки необходимо провести предварительную настройку окружения, поднять контейнеры и прописать связи. 

Но, прежде чем поднимать контейнеры, давайте разберем, как эти три инструмента общаются между собой и почему нужен именно такой «бутерброд». 

Дело в строгом разделении обязанностей. Работает этот конвейер следующим образом:

1. k6 (Генератор и Измеритель) — наш «работяга». Его единственная задача — с большой скоростью имитировать действия пользователей, отправлять запросы на ваш сервер и с секундомером замерять, как быстро пришел ответ. Как только k6 получает ответ от вашего сервера, он формирует метрику (например: «запрос на /api/login отработал за 150 мс, статус 200»). Но k6 спроектирован так, чтобы потреблять минимум памяти. Он не умеет и не хочет накапливать миллионы этих метрик внутри себя. Ему нужно куда-то их выгружать прямо на лету. И тут появляется база данных.

2. InfluxDB (Хранилище / Склад метрик), куда метрики из k6 льются непрерывным потоком. Почему мы берем именно её, а не привычную PostgreSQL или MySQL? InfluxDB — это Time-Series Database (TSDB), то есть база данных временных рядов. Она архитектурно заточена под то, чтобы каждую миллисекунду принимать тысячи записей, привязанных к конкретной временной метке (timestamp). InfluxDB не строит графики, а просто складирует каждую миллисекунду вашего теста, чтобы ничего не потерялось.

3. Grafana (Витрина / Визуализатор) — это «красивое лицо» нашего мониторинга. Важно понимать: Grafana сама по себе ничего не тестирует и не хранит. Это просто очень умный дашборд (по сути, веб-интерфейс). Grafana подключается к InfluxDB (как к источнику данных) и каждую секунду отправляет к ней запросы. InfluxDB отдает цифры, а Grafana мгновенно превращает их в графики, которые мы так любим показывать бизнесу.

Чтобы вся эта связка заработала, необходим Docker, потому что в папке проекта мы создадим файл docker-compose.yml со следующим содержимым: 

version: '3.8'

services:
  influxdb:
    image: influxdb:1.8
    container_name: influxdb
    ports:
      - "8086:8086"
    environment:
      - INFLUXDB_DB=k6


  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3001:3000"
    environment:
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
      - GF_AUTH_ANONYMOUS_ENABLED=true
    depends_on:
      - influxdb

Далее в терминале запускаем docker-compose up -d. Теперь у нас на компьютере работают база данных (порт 8086) и панель графиков (порт 3000).

После того как все поднялось, можно настраивать Grafana и графики в ней. Для этого заходим на http://localhost:3000, в открывшемся окне переходим в Connections -> Data Sources -> Add new data source.

Выберите InfluxDB.

В настройках:

• URL: http://influxdb:8086

• Database: k6

• Нажмите Save & Test. Должно появиться зеленое сообщение.

Нам осталось настроить сами графики, то как они будут выглядеть и что отображать. Для этого нажимаем «Build a dashboard».

А далее «Import a dashboard».

Импортировать дашборд можно двумя способами:

1. Импорт дашборда подходящего под ваши цели с сайта  grafana.com/dashboards, где собрана большая коллекция всевозможных дашбордов, созданных пользователями.

   

Найти нужный можно используя фильтры или по схожему названию. После этого надо найти ID номер выбранного дашборда.

Далее этот ID необходимо ввести в поле и нажать «Load».

После этого выбранный дашборд с официального сайта подтянется в вашу локальную Grafana и можно будет использовать уже преднастроенные заранее графики.

2. Есть возможность импортировать дашборд, не загруженный на официальный сайт Grafana. Например, дашборд вашего коллеги. Для этого он должен осуществить экспорт дашборда в JSON-файле (такая возможность в Grafana присутствует), а вы затем просто загрузите этот JSON-файл через импорт.

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

Создание собственного дашборда

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

Для создания своего дашборда достаточно нажать кнопку «Dashboards», а затем «New»-«New dashboard».

Далее «Add visualization», после чего необходимо выбрать наш источник данных, подключенный ранее, который мы будем использовать.

Как только мы определились с источником, можно настраивать первый график дашборда. 

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

Нам необходимо выбрать, какие данные мы хотим отображать из базы данных. По сути мы формируем запрос к БД, и видим стандартные операторы FROM, SELECT, GROUP BY и др. А также нам необходимо выбрать настройки самого графика (его название, толщина, цвет и остальные параметры) в правой панели под названием «Panel options».

Количество и состав графиков вашего дашборда зависит от вашей фантазии и потребностей. Лично я собрал четыре наиболее полезных графика:

1. Active Users (VUs)
   

   

2. Время отклика (Response Time)

   

3. Запросы в секунду (RPS)
   

   

4. Ошибки (HTTP Errors)
   

   

Осталось сохранить графики и приступить к тестированию. Реальные графики будут выглядеть следующим образом:

Их очень просто интерпретировать и анализировать. Например, сопоставив график времени отклика и график ошибок можно понять, какой запрос вызвал ошибку. А график виртуальных пользователей показывает какой тип нагрузки был использован при тестировании (spike, stress и т.д.). 

Единственная рекомендация по настройке всего дашборда: в правой верхней панели выставить значение обновления графиков каждые 5 секунд, а вывод самих графиков отрегулировать по длине самого теста. например, 15 минут. Это позволит вывести только полезную часть графика, чтобы не было пустот справа, когда никакие данные не летят, и соответственно никакие графики не генерируются.

После установки и настройки дашбордов можно запускать тесты с флагом в команде:

k6 run --out influxdb=http://localhost:8086/k6 script.js  (где script.js — название вашего скрипта)

Как только команда запустится и тесты начнутся, переходите в браузер в Grafana. Вы увидите, как графики начинают рисоваться в реальном времени. 

Итоги:

Плюсы: Максимальная информативность в реальном времени.

Минусы: Требуется Docker и настройка коннектов. Кроме того, импортированные со стороны дашборды с большой вероятностью будут работать криво или вообще не запустятся, поэтому самый лучший вариант — создавать их самостоятельно.

Когда применять: При проведении длительных и серьезных нагрузочных сессий, когда необходимо детально отслеживать поведение приложения в динамике. Способ незаменим, если вы хотите создать профессиональный и полностью кастомизированную панель управления нагрузкой.

Бонус: Автоматизируем всё (Starter Kit)

Мы с вами только что прошли весь путь ручной настройки: от создания контейнеров до создания запросов и настройки дашбордов в Графане. Это отличный опыт, но в реальной жизни хочется, чтобы всё работало из коробки.

Специально для этой статьи я собрал готовый Starter Kit на GitHub. В нем я автоматизировал всю рутину с помощью механизма Provisioning в Grafana.

Что внутри:

• Изолированные порты (Grafana на 3002, InfluxDB на 8087), чтобы стенд не конфликтовал с вашими рабочими проектами.

• Auto-provisioning: полностью настроенный дашборд появляется в Графане сам при старте контейнера. Вам не нужно кликать интерфейс и писать запросы (QL) руками.

• Умный скрипт-паук: готовый k6-скрипт (sitemap_spider.js), который парсит sitemap.xml, распределяет ссылки между виртуальными пользователями и, что самое полезное, выводит битые ссылки (не 200-е статусы) прямо в консоль.

Как запустить за 2 минуты:

1. Клонируем репозиторий: git clone https://github.com/VasilKham/k6-load-test-starter-kit.git cd k6-load-test-starter-kit 

2. Поднимаем стенд одной командой: docker-compose up -d 

3. Открываем в браузере http://localhost:3002 (дашборд уже ждет вас). 

4. Запускаем нашего паука: npm run test:spider 

Заключение

Локальное нагрузочное тестирование не должно превращаться в мониторинг бегущих строк в консоли. Как мы убедились на личном опыте, красивый зеленый текст 0 errors еще не означает, что ваш сервер действительно справляется с реальной нагрузкой, а не просто отдает быстрые ошибки валидации.

Выбор инструмента визуализации зависит от ваших текущих задач:

• Для быстрого анализа «на коленке» и поиска нестандартных корреляций отлично подойдут нейросети.

• Для фиксации результатов в таск-трекере — HTML-репортеры.

• Для быстрого наблюдения в моменте без лишних настроек — встроенный Web Dashboard.

• А для серьезного, глубокого тестирования и создания профессионального пульта управления нагрузкой незаменима связка k6 + InfluxDB + Grafana.

Потратив однажды полчаса на настройку собственного локального дашборда, получаем мощный инструмент, который сэкономит десятки часов на дебаге и поиске узких мест вашего проекта в будущем.