P
perfscale

Концепции

Стриминг живых метрик

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

Обзор

Прогон наблюдаем, пока он ещё подаёт нагрузку — а не только когда придёт итоговая сводка. Движок на машине каждые несколько секунд снимает кумулятивный снапшот всех собранных метрик и стримит его на платформу; страница прогона рисует графики по мере прихода сэмплов, а тот же поток питает дашборд Metrics, Prometheus-совместимый query API и Remote Write. Никаких InfluxDB и внешних коллекторов — поток встроен в сам прогон.

Как включить

Добавьте блок report: с during_run: true в Configuration, с которой запускается тест, — в редакторе конфигураций для этого есть сниппет During-run metrics:

report:
  during_run: true        # по умолчанию false — только итоговая сводка
  interval_ms: 5000       # интервал снапшотов/флаша, минимум 1000
  batch_size: 500         # запечатать батч при таком числе сэмплов
  max_cpu_percent: 90     # CPU-гейт; 0 отключает его (Linux)
  max_pending: 24         # мягкий предел — предупреждение, батчи не выбрасываются

Остальное делает агент: он аутентифицирует поток машинным токеном и метит каждый сэмпл лейблами task_id и machine_id, так что распределённый прогон чисто раскладывается по генераторам нагрузки.

Стриминг работает для нативного движка. Скрипты k6, JMeter и Locust по-прежнему дают нормализованную итоговую сводку и живые логи, но during-run сэмплы не стримят.

Что шлёт движок

Каждый снапшот разворачивает все семейства метрик прогона в сэмплы по конвенциям Prometheus (длительности в секундах):

Метрика движкаОтправляемые сэмплы
Гистограмма (http_req_duration, свои тренды)<name>{quantile="0.5"/"0.9"/"0.95"/"0.99"}, <name>_count, <name>_sum
Счётчик<name>_total
Доля ошибок (http_req_failed, …)<name>_total (вызовы), <name>_failed_total (ошибки)
GPU-гауг (при gpu.enabled)gpu_utilization_pct, gpu_memory_used_mib, gpu_temperature_c, gpu_power_w по устройствам — на Apple Silicon также ane_power_w, cpu_power_w, package_power_w

Пользовательские метрики ваших шагов — латентность gRPC, время запросов к БД, llm_ttft_ms, счётчики WebSocket — подхватываются автоматически; настраивать ничего не нужно.

Снапшоты кумулятивные (гистограммы и счётчики не сбрасываются в середине прогона); платформа диффает соседние снапшоты, чтобы рисовать значения за интервал. GPU-гауги — точечные значения и чартятся как есть.

Как ведёт себя доставка

Батч запечатывается при batch_size сэмплов или по тику interval_ms — что наступит раньше — и уходит на платформу со строго возрастающим seq. Ингест дедуплицирует по (task_id, seq), так что переотправленный батч никогда не задвоит данные. Когда прогон завершается, всё оставшееся в очереди сливается (финальный дренаж, предел 30 секунд), а следом приходит обычная итоговая сводка.

Защита генератора нагрузки

Shipper живёт по одному правилу: генерация нагрузки всегда важнее отчётности о ней.

  • Движок никогда не блокируется на метриках — снапшоты идут через ограниченный канал, а переполненный канал выбрасывает снапшот, а не тормозит виртуальных пользователей.
  • CPU-гейт: пока busy-CPU машины держится на уровне max_cpu_percent или выше (по умолчанию 90%, Linux), shipper придерживает все батчи и складывает входящие снапшоты в очередь, а не выбрасывает их — ноль отправок, пока машина не придёт в себя, затем накопленные точки уходят по порядку. Если генератор упёрся в потолок, perfscale замолкает, а не дерётся с виртуальными пользователями за последние ядра.
  • Точки не выбрасываются в середине прогона: запечатанные, но недоставленные батчи хранятся, сколько бы ни длился сбой. max_pending — мягкий предел: при превышении пишется предупреждение, а доставка продолжается по порядку, как только платформа отвечает.
  • Сетевые ошибки, 5xx и 429 ретраят тот же батч с тем же seq (бэкофф с потолком 60 с); любой другой 4xx выбрасывает отравленный батч и идёт дальше.

Полный инженерный контракт — в OSS-справочнике: During-run metrics.

Как читать метрики

  • Страница прогона — графики рисуются по мере прихода сэмплов: перцентили задержки, пропускная способность, доля ошибок, кривые GPU. Без обновления страницы и ожидания сводки.
  • Дашборд Metrics — определяет протокол прогона по стримящимся семействам и подставляет подходящий набор плиток (Протокольные метрики).
  • Grafana — платформа отдаёт Prometheus-совместимый query API. Settings → Integrations показывает URL датасорса (<инстанс>/api/v1/integrations/prometheus); аутентификация — персональным API-токеном из Settings → Keys (Authorization: Bearer psk_…). Запрашивайте как любой Prometheus — rate(http_req_duration_count[1m]), раскладка по machine_id и т.д.
  • Remote Write — удобнее своё хранилище? Settings → Integrations → Prometheus Remote Write пушит каждый принятый сэмпл в ваш Prometheus, Mimir, VictoriaMetrics или Grafana Cloud, с опциональной basic/bearer аутентификацией.

Дальше