Метрики и дашборды
Пересвет-СТ собирает метрики в реальном времени и экспортирует их в ClickHouse. Для визуализации результатов используется Grafana — каждому типу плагина соответствует один или несколько преднастроенных дашбордов. Дашборды доступны из веб-интерфейса Пересвет-СТ при запущенной задаче.
Экспорт отчётов PDF/CSV/HTML и перенос задач (архив / JSON) описаны в разделе Экспорт отчетов и импорт задач.
Как читать секундные метрики
Метрики Пересвет-СТ показывают фактическое поведение трафика на коротких интервалах. На большинстве графиков точка соответствует измерению за 1 секунду: сколько запросов, ответов, пакетов, байт или бит было реально сгенерировано, передано, принято или обработано именно в этом секундном окне.
Система не сглаживает такие графики искусственно на 5 или 10 секунд и не подрисовывает «идеальную» линию целевого профиля. Поэтому на графике может быть видна небольшая естественная неравномерность: одна секунда оказывается немного ниже целевого значения, следующая - немного выше. Это нормальное свойство точного секундного измерения, особенно для TCP, HTTP и сценариев с большим числом параллельных сессий.
В реальной сети трафик также не приходит идеально одинаковыми порциями каждую секунду. TCP-соединения устанавливаются и закрываются во времени, HTTP-запрос зависит от готовности соединения и ответа, пакеты группируются сетевой картой и обрабатываются несколькими ядрами агента, а границы секундных интервалов не совпадают с границами отдельных сессий. Если часть событий попадает на границу двух секунд, соседние точки графика могут немного отличаться, при этом среднее значение на рабочем интервале и суммарный объем трафика соответствуют заданному профилю.
Практически это означает:
- для проверки скорости используйте участок плато после разгона и до остановки задачи;
- учитывайте параметры CPS и CC: если задача открывает 100 новых соединений в секунду до 1000 активных соединений, плато появится не мгновенно, а после разгона;
- оценивайте среднее значение на выбранном интервале и общий объем за интервал, а не только одну отдельную секундную точку;
- сравнивайте программные и аппаратные метрики: программные показывают, что было сгенерировано и обработано сценарием, аппаратные - что физически прошло через сетевой интерфейс;
- отдельно проверяйте Drops и потери: при нулевых потерях небольшие колебания секундных значений обычно отражают точность измерения, а не проблему генерации.
На примере HTTP-задачи с целевым профилем 10000 запросов в секунду видно, что после разгона линия держится около заданного значения. Отдельные секундные точки могут показывать 9.9K или чуть больше 10K запросов в секунду, но рабочее среднее на плато соответствует целевому профилю.
Рис. 24 — HTTP-нагрузка 10K RPS: точные секундные значения вокруг целевого профиля
Похожее поведение может быть видно и на общих графиках пакетов или битов. Если профиль задан как постоянная скорость, но график построен по фактическим 1-секундным интервалам, небольшая «ступенчатость» или компенсация в соседней секунде допустимы. Для приемки результата важны рабочее плато, среднее значение, общий объем трафика и отсутствие потерь.
Рис. 25 — Общий TX-график: фактические 1-секундные интервалы без искусственного сглаживания
Основные группы метрик
В дашбордах используются несколько типов показателей. Они описывают разные уровни одного и того же теста, поэтому их нужно читать совместно.
| Группа | Что показывает | Как интерпретировать |
|---|---|---|
| Requests / Responses | Прикладные операции: HTTP-запросы и ответы, DNS-запросы и ответы, операции передачи файлов и другие события L7 | Используйте для проверки бизнес-профиля приложения: сколько прикладных действий реально выполнено за секунду или за весь интервал |
| Packets | Количество сетевых пакетов TX/RX | Один прикладной запрос может соответствовать одному или нескольким пакетам. При TLS, крупных ответах, фрагментации или повторной передаче число пакетов не обязано совпадать с числом запросов |
| Bytes / Bits | Объем переданных данных и скорость передачи | Подходит для оценки полезной нагрузки и L2/L3-скорости. Если размер пакетов фиксирован, Bits и Packets обычно меняются синхронно |
| L1 / L2 Bits | Скорость на разных уровнях учета | L2 отражает объем Ethernet-кадров, L1 дополнительно учитывает физические накладные расходы линии, поэтому именно L1 используется для оценки line rate |
| TCP Connections | CPS, активные, закрытые и ожидающие соединения | CPS показывает скорость открытия TCP-соединений, Active connections / CC - текущую конкурентность, Closed - завершение соединений, Pending - соединения в процессе установления |
| Drops / Loss | Потери, отброшенные пакеты и ошибки приема/передачи | Для качества теста смотрите drops/loss после завершения задачи. Во время прогона в «Общей статистике» кратковременные потери могут быть артефактом рассинхрона метрик между агентами — см. ниже |
| Generated / Software | Счетчики сценария внутри агента | Показывают, сколько трафика сценарий сформировал, обработал и учел на уровне приложения или сетевого стека |
| Hardware / Physical | Аппаратная статистика сетевого интерфейса | Показывает фактический трафик на физическом порту: line rate, L1/L2 bits, аппаратные пакеты и ошибки интерфейса |
Программные и аппаратные метрики не заменяют друг друга. Программные метрики удобны для проверки логики сценария: запросов, ответов, сессий, приложений, кодов ответа, задержек и ошибок. Аппаратные метрики подтверждают, что трафик действительно вышел на порт и был принят сетевой картой. При анализе результата сначала проверьте, что сценарий вышел на плато, затем сравните software и hardware, после этого оцените drops/loss.
Персонализированные дашборды
Персонализированные дашборды дополняют стандартные метрики задачи специализированными срезами для отдельных сценариев испытаний. Каждый такой дашборд решает свою задачу анализа и может быть включен независимо от остальных.
По умолчанию персонализированные дашборды не включены, поскольку для них агент собирает дополнительную детализацию трафика. Перед запуском задачи администратор должен открыть Настройки → Дашборды, нажать «Выбрать дашборды», отметить нужные дашборды и применить изменения. Дополнительные метрики начнут собираться при следующем запуске задачи; для уже запущенной или ранее завершенной задачи они не рассчитываются задним числом.
После включения выбранные дашборды появляются на вкладке Метрики подходящих задач.
Балансировка по ответчикам
«Балансировка по ответчикам» предназначен для испытаний балансировщиков нагрузки, DSR/IP-IP-схем и других решений, которые распределяют входящий трафик между несколькими серверными IP-адресами. Дашборд дополняет общие метрики задачи отдельным срезом по каждому ответчику и помогает проверить не только суммарную скорость, но и равномерность фактического распределения нагрузки.
Дашборд группирует метрики по IP-адресам ответчиков и показывает трафик, входящий на сторону ответчиков: то, что клиент отправил серверам. Обратный поток — данные, которые серверы отправили в ответ и клиент принял, — отображается на общих дашбордах как Server TX / Client RX и в этот RX-срез по ответчикам не входит. Поэтому при небольших запросах и крупных ответах Client RX может быть значительно выше RX на ответчиках — это разные направления одного обмена, а не ошибка.
Дашборд показывает:
| Блок | Что показывает |
|---|---|
| Активные / всего ответчиков | Число IP-адресов, получавших входящий трафик, и общий размер наблюдаемой группы ответчиков (Responder Size) |
| Без входящего трафика | Количество ответчиков, которым не поступал трафик на выбранном интервале |
| Максимальное отклонение TCP CPS | Наибольшее отклонение скорости установления TCP-соединений отдельного ответчика от среднего значения по группе |
| Топ-10 недогруженных / перегруженных | IP-адреса с наибольшим отрицательным и положительным отклонением от среднего распределения |
| Детализация выбранных ответчиков | TCP CPS, TCP CC, ожидающие и закрытые соединения, входящий трафик в битах и пакетах для выбранных IP-адресов |
Рис. 25а — Сводка распределения нагрузки между IP-адресами ответчиков
Дашборд рассчитан на отдельный анализ группы размером до 256 IP-адресов ответчиков в одном тестовом профиле. При большем числе адресов общие метрики задачи продолжают показывать суммарный трафик, но Responder Size и детализация распределения по отдельным IP могут быть неполными.
Общие метрики (Total)
Дашборд Total и блок «Общая статистика» показывают агрегированные показатели по задаче: отправлено / принято / потеряно по направлениям между агентами (пакеты и биты).
| Метрика | Описание |
|---|---|
| total.rx.packets / total.tx.packets | Общее количество принятых / отправленных пакетов |
| total.rx.bytes / total.tx.bytes | Общий объём принятых / отправленных данных (байт) |
| total.tx.drop | Количество отброшенных пакетов при отправке |
| total.pkt.lost | Количество потерянных пакетов |
| total.rx.bad | Количество принятых некорректных пакетов |
| total.tx.l1_bits / total.rx.l1_bits | Битрейт L1 (с учётом межкадровых интервалов и преамбул) TX / RX |
| total.tx.line_rate / total.rx.line_rate | Утилизация линии (%) TX / RX |
| total.cpu_usage | Загрузка CPU ядер обработки |
| total.tos.rx | Принятые пакеты с анализом поля ToS |
| total.rx.imissed | Пакеты, пропущенные NIC (переполнение очереди) |
| total.rx.ierrors | Ошибки приёма на уровне NIC |
Общая статистика: потери во время выполнения
В таблицах «Общая статистика (пакеты)» и «Общая статистика (биты)» потери считаются как разница между отправленным на одной стороне и принятым на другой (по направлению агент → агент и интерфейсам).
Агенты пишут метрики в ClickHouse независимо и не синхронизируют момент отправки батча. Пока задача идёт, на дашборде можно увидеть небольшой «пролаг»: на одном агенте счётчик TX уже обновился, а RX на втором ещё нет (или наоборот). Тогда на секунду–минуту проскакивает ненулевая Потеряно / Потери (%), а чуть позже значение уменьшается или уходит в ноль, когда подтягивается «отстающая» сторона. Насколько это заметно, зависит от скорости трафика и от того, в какой момент вы открыли вкладку Метрики.
Особенно это проявляется, если в задаче два разных агента (клиент и сервер на разных машинах). Если оба плеча сидят на одном агенте с двумя интерфейсами, рассинхрон обычно слабее, но кратковременный перекос всё равно возможен.
Для приёмки смотрите общую статистику после полного и стабильного завершения задачи, когда оба агента дописали финальные метрики. Итоговые потери на остановленной задаче — основной ориентир; мимолётные ненулевые потери во время прогона сами по себе не означают реальный дроп на DUT.
Аномалии на агентах
Таблица «Аномалии на агентах» на дашборде Total (Dual) показывает пакеты и события, отброшенные сетевой картой или программным стеком на конкретном агенте. Это локальные диагностические счётчики: они не равны потерям между клиентом и сервером из блока «Общая статистика» и сами по себе не доказывают, что пакеты потерял DUT.
Значения рассчитываются как прирост счётчика за выбранный на дашборде интервал времени и группируются по агенту и интерфейсу. Ноль означает, что за этот интервал счётчик не увеличивался.
| Колонка | Что означает |
|---|---|
| Агент | Имя агента, на котором зафиксирована аномалия |
| Интерфейс | Сетевой интерфейс агента, к которому относится счётчик |
| TX drop | Пакеты, которые программный стек подготовил к отправке, но не смог поместить в очередь передачи. Рост обычно означает, что агент или NIC не успевает передавать сформированный трафик |
| RX missed | Пакеты, пропущенные NIC до передачи в программный стек, например при переполнении приёмной очереди. Частый признак того, что агент не успевает вычитывать RX на текущей нагрузке |
| RX discards | Внутренние отбрасывания на стороне NIC. Для Mellanox это счётчик rx_phy_discard_packets, который может расти при ограничениях внутреннего конвейера карты или обмена по PCIe |
| RX errors | Ошибки приёма, зарегистрированные NIC или драйвером |
| RX bad | Пакеты, дошедшие до программного стека, но признанные некорректными: например, с ошибкой контрольной суммы, неверным форматом или ошибкой разбора/декапсуляции |
| RX no_ws | Для принятого пакета не найден подходящий рабочий контекст задачи на агенте. Проверьте соответствие протокола, адресов, интерфейса и конфигурации, а также маршрутизацию пакета на нужную очередь обработки |
| RX nombuf | NIC не смог получить свободный буфер для очередного принятого пакета. Рост указывает на нехватку пакетных буферов или их несвоевременное освобождение при высокой нагрузке |
| TCP drop | Общее количество пакетов, отброшенных программным TCP-стеком агента. В него входят как показанные рядом причины, так и другие причины TCP drop |
| Bad seq server | На клиентском агенте получен пакет от сервера, чьи TCP sequence/ACK не соответствуют состоянию найденного клиентского сокета |
| No socket client | На клиентском агенте принят пакет для настроенного диапазона адресов, но активный клиентский TCP-сокет для этого соединения не найден. Возможные причины: поздний пакет после закрытия соединения, неожиданная комбинация IP-адресов и портов, доставка пакета не на тот контекст обработки или рассинхронизация состояния под нагрузкой |
| SYN/ACK bad ACK | Клиент получил SYN/ACK с номером подтверждения, который не соответствует отправленному SYN; такой ответ не может завершить TCP-handshake и отбрасывается |
| Bad seq client | На серверном агенте получен пакет от клиента, чьи TCP sequence/ACK не соответствуют состоянию найденного серверного сокета |
| Всего | Сумма TX drop, аппаратных и общих RX-аномалий и TCP drop. Колонки с отдельными причинами TCP drop повторно не прибавляются, поэтому один TCP drop не учитывается дважды |
HTTP / TLS
Дашборд Total HTTP/TLS — агрегация по всем HTTP-плагинам. Дашборд HTTP/TLS — детализация по конкретному плагину.
| Метрика | Описание |
|---|---|
| http_1_1.tx.requests / http_1_1.rx.responses | Отправленные запросы / полученные ответы (HTTP/1.1) |
| http_1_1.tx.bytes / http_1_1.rx.bytes | Объём данных TX / RX |
| http_1_1.code.1xx–5xx | Распределение HTTP-кодов ответа (1xx, 2xx, 3xx, 4xx, 5xx) |
| http_1_1.ttfb | Avg. TTFB — от отправки HTTP/1.1-запроса до обработки первого байта ответа клиентом |
| http_1_1.ttlb | Avg. TTLB — от отправки HTTP/1.1-запроса до обработки полного ответа клиентом |
| http_1_1.wire_ttfb | Wire TTFB — от отправки HTTP/1.1-запроса до аппаратной фиксации первого байта ответа на сетевой карте клиента |
| http_1_1.method.get/post/put/patch/delete | Количество запросов по HTTP-методам |
| http_2.tx.requests / http_2.rx.responses | Отправленные запросы / полученные ответы (HTTP/2) |
| http_2.code.1xx–5xx | Распределение HTTP-кодов ответа (HTTP/2) |
| http_2.ttfb / http_2.ttlb | Avg. TTFB / TTLB — время до первого байта и полного HTTP/2-ответа |
| http_2.streams.opened/closed/reseted | Количество открытых / закрытых / сброшенных стримов HTTP/2 |
| tcp.cps | TCP Connections Per Second — новых соединений в секунду |
| tcp.cc | TCP Concurrent Connections — текущие активные соединения |
| tcp.hs_avg_delay | Avg. HS delay — от отправки SYN до обработки SYN/ACK программным TCP-стеком клиента |
| tcp.hs_wire_avg_delay | Wire RTT — от отправки SYN до аппаратной фиксации SYN/ACK на сетевой карте клиента |
| TCP Data RTT Avg | Среднее время от отправки выбранного TCP-сегмента с данными до подтверждающего ACK; рассчитывается по точным значениям, повторные передачи исключаются |
| TCP Data RTT P50 / P95 / P99 | Перцентили Data RTT; значение округляется вверх до ближайшей границы диапазона — например, 15 мс означает больше 10 мс, но не больше 15 мс |
| TCP Wire Data RTT Avg / P50 / P95 / P99 | То же измерение с аппаратной фиксацией входящего ACK на сетевой карте клиента |
| TCP Data RTT Jitter | Среднее изменение Data RTT между соседними измерениями |
| TCP Data RTT Samples | Количество завершённых измерений и измерений, исключённых из-за повторной передачи |
| tls_1_2.hs_avg_delay / tls_1_3.hs_avg_delay | Avg. HS delay — время установления TLS-сессии после завершения TCP-хендшейка |
| tls_1_2.* / tls_1_3.* | Остальные метрики TLS 1.2 / 1.3: пакеты, байты, CPS, CC и Client/Server Hello |
Метрики задержки показывают весь путь, наблюдаемый с клиентского агента: прохождение через тестируемое устройство, обработку на серверном агенте и возврат ответа. TCP Data RTT измеряется от постановки выбранного сегмента в очередь передачи до получения подтверждающего ACK. Wire Data RTT фиксирует приём ACK аппаратной меткой на сетевой карте клиента, но также включает ожидание отправки на серверном агенте.
При загрузке линии около 100% ACK может ожидать отправки за пакетами данных, поэтому P95/P99 растут даже без потерь и повторных передач. Чтобы сравнивать влияние DUT, убедитесь, что агенты не являются узким местом, и оставьте запас 5–10% по L1.
Wire RTT, Wire Data RTT и Wire TTFB требуют аппаратной совместимости и доступны только на ПАК Пересвет-СТ. На виртуальных машинах и при других вариантах развёртывания эти метрики недоступны.
Измерение задержек (IP/UDP)
Дашборд Измерение задержек (IP/UDP) показывает результат работы одноимённого плагина. Задержка рассчитывается на клиентском агенте по ответам серверной стороны.
| Панель / метрика | Описание |
|---|---|
| CLIENT | UDP RTT — Avg RTT | Среднее время от отправки измеренного UDP-запроса до получения ответа клиентским агентом |
| CLIENT | UDP RTT — P50 / P95 / P99 RTT | 50-й, 95-й и 99-й перцентили RTT; значение округляется вверх до ближайшей границы диапазона |
| CLIENT | UDP Wire RTT — Wire RTT | Средний RTT контрольного потока с аппаратной фиксацией приёма ответа на сетевой карте клиента |
| CLIENT | UDP Wire RTT — P50 / P95 / P99 Wire RTT | Перцентили Wire RTT контрольного потока с аппаратной фиксацией приёма ответа |
| CLIENT | UDP RTT Jitter — Avg RTT jitter | Среднее абсолютное изменение RTT между соседними измеренными ответами |
| CLIENT | UDP RTT Jitter — Wire RTT jitter | То же изменение для Wire RTT |
| CLIENT | Измеренные пробы — RTT samples/s | Число ответов за секунду, вошедших в расчёт RTT |
| CLIENT | Измеренные пробы — Wire RTT samples/s | Число ответов контрольного потока за секунду, для которых получена аппаратная метка времени |
| CLIENT | UDP запросы и ответы | Все отправленные UDP-запросы и полученные ответы; временная разница между линиями возможна на границе секундного интервала |
Пакеты отправляются с заданной скоростью, а RTT и jitter рассчитываются по равномерной выборке. Поэтому количество измеренных проб может быть меньше количества запросов. RTT включает прямой и обратный путь через тестируемое устройство, а также обработку ответа серверным агентом.
UDP RTT измеряется от постановки выбранного UDP-запроса в очередь передачи до получения ответа клиентским агентом. Wire RTT фиксирует приём ответа аппаратной меткой на сетевой карте клиента, но также включает ожидание отправки ответа на серверном агенте.
При загрузке линии около 100% UDP-ответ может ожидать отправки за другими пакетами, поэтому P95/P99 растут даже без потерь. Чтобы сравнивать влияние DUT, убедитесь, что агенты не являются узким местом, и оставьте запас 5–10% по L1.
Wire RTT и Wire RTT jitter требуют аппаратной совместимости и доступны только на ПАК Пересвет-СТ. На виртуальных машинах и при других вариантах развёртывания эти метрики недоступны.
TCP Flood (SYN / SYN-ACK / ACK / RST / RST-ACK / FIN / FIN-ACK / PSH / PSH-ACK / Xmas)
Дашборд Total TCP — агрегация по всем TCP flood плагинам. Для каждого типа flood есть отдельный дашборд (например, TCP SYN, TCP ACK, TCP Xmas и т.д.).
| Метрика | Описание |
|---|---|
| tcp.tx.flags.syn / tcp.rx.flags.syn | Отправленные / принятые SYN-пакеты |
| tcp.tx.flags.syn_ack / tcp.rx.flags.syn_ack | Отправленные / принятые SYN-ACK-пакеты |
| tcp.tx.flags.ack / tcp.rx.flags.ack | Отправленные / принятые ACK-пакеты |
| tcp.tx.flags.rst / tcp.rx.flags.rst | Отправленные / принятые RST-пакеты |
| tcp.tx.flags.rst_ack / tcp.rx.flags.rst_ack | Отправленные / принятые RST-ACK-пакеты |
| tcp.tx.flags.fin / tcp.rx.flags.fin | Отправленные / принятые FIN-пакеты |
| tcp.tx.flags.fin_ack / tcp.rx.flags.fin_ack | Отправленные / принятые FIN-ACK-пакеты |
| tcp.tx.flags.psh / tcp.rx.flags.psh | Отправленные / принятые PSH-пакеты |
| tcp.tx.flags.psh_ack / tcp.rx.flags.psh_ack | Отправленные / принятые PSH-ACK-пакеты |
| tcp.tx.flags.xmas / tcp.rx.flags.xmas | Отправленные / принятые Xmas-пакеты (все флаги) |
| tcp.tx.packets / tcp.rx.packets | Общее количество TCP-пакетов TX / RX |
| tcp.tx.bytes / tcp.rx.bytes | Объём TCP-данных TX / RX |
UDP Flood
Дашборд Total UDP — агрегация. Дашборд UDP — детализация.
| Метрика | Описание |
|---|---|
| udp.tx.packets / udp.rx.packets | Отправленные / принятые UDP-пакеты |
| udp.tx.bytes / udp.rx.bytes | Объём UDP-данных TX / RX |
| udp.rt | Время отклика (round-trip) UDP |
| udp.drop | Потерянные UDP-пакеты |
Fuzzing (L3-L7)
Дашборд Fuzzing (L3-L7) отображает результат работы включенных UDP/TCP-модулей Fuzzing и flow-сценариев. Он используется для проверки фактической скорости отправки, объема трафика и состояния L4-сессий во время теста.
| Блок дашборда | Что показывает |
|---|---|
| Обзор L3-L4 фаззинга | Сводное состояние задачи и активность Fuzzing-профиля на выбранном интервале |
| UDP: отправленные пакеты | Отдельные линии по включенным UDP-модулям: неверная чексумма, TTL, DSCP/ECN, IP ID, Payload Data и UDP Flow |
| TCP: отправленные пакеты | Отдельные линии по включенным TCP-модулям: PSH/ACK, неверная чексумма, SEQ, MSS, Window Scale, TCP window, Payload Data и TCP Flow |
| UDP: отправленные байты / биты | Объем UDP-трафика и скорость передачи в байтах/битах |
| TCP: отправленные байты / биты | Объем TCP-трафика и скорость передачи в байтах/битах |
| L4-сессии / flow | Состояние TCP-сессий и UDP flow при включенных flow-модулях |
| TCP Connections | Создание, активность и закрытие TCP-сессий |
| UDP Flow Sessions | Количество и активность UDP flow |
Если в задаче включено несколько модулей Fuzzing, сравнивайте линии UDP: отправленные пакеты и TCP: отправленные пакеты с заданным бюджетом Пакетов в секунду. Это помогает проверить, что нагрузка распределилась между выбранными модулями ожидаемым образом.
GRE Flood
Дашборд Total GRE — агрегация. Дашборд GRE — детализация.
| Метрика | Описание |
|---|---|
| gre.tx.packets / gre.rx.packets | Отправленные / принятые GRE-пакеты |
| gre.tx.bytes / gre.rx.bytes | Объём GRE-данных TX / RX |
DNS Flood
Дашборд Total DNS Flood — агрегация. Дашборд DNS Flood — детализация.
| Метрика | Описание |
|---|---|
| dns_flood.tx.packets / dns_flood.rx.packets | Отправленные / принятые DNS Flood-пакеты |
| dns_flood.tx.bytes / dns_flood.rx.bytes | Объём DNS Flood-данных TX / RX |
ICMP / Ping / Fragmentation / Amplification
| Дашборд (ключ) | Плагин |
|---|---|
ddos_icmp_flood | ICMP Flood (103) |
ddos_icmp_fragmentation | ICMP Fragmentation Flood (104) |
ddos_ping_flood | Ping Flood (105) |
ddos_ping_of_death | Ping of Death Flood (106) |
ddos_dns_amplification | DNS Amplification UDP (107) |
ddos_udp_fragmentation | UDP Fragmentation Flood (108) |
ddos_ntp_amplification | NTP Amplification UDP (110) |
Компрометированный хост
Дашборд compromised_host — сессии, шаги, таймауты и маяк C2.
DHCP Flood (legacy)
Дашборд Total DHCP Flood — агрегация. Дашборд DHCP Flood — детализация.
| Метрика | Описание |
|---|---|
| dhcp_flood.tx.packets / dhcp_flood.rx.packets | Отправленные / принятые DHCP Flood-пакеты |
| dhcp_flood.tx.bytes / dhcp_flood.rx.bytes | Объём DHCP Flood-данных TX / RX |
WAF
Дашборд WAF отображает результаты тестирования Web Application Firewall — количество отправленных запросов по каждой категории атак:
| Группа метрик | Описание |
|---|---|
| waf.broken_access_control, waf.injection.*, waf.xss.*, waf.ssrf и др. | Базовое тестирование: по одной метрике на каждый тип атаки (18 категорий) |
| waf.sqli.* | SQLi Advanced: 50 типов SQL-инъекций |
| waf.xxe.* | XXE Advanced: 4 типа атак на XML-парсер |
| waf.cmdi.* | Command Injection Advanced: 18 типов OS-команд |
| waf.fi.* | File Injection Advanced: 8 типов включения файлов |
| waf.pt.* | Path Traversal Advanced: 17 типов обхода путей |
| waf.unc.* | UNC Path: 4 типа атак через UNC-пути |
| waf.rce.* | RCE Advanced: 6 типов удалённого выполнения кода |
| waf.xss.* (advanced) | XSS Advanced: 19 типов межсайтового скриптинга |
| waf.ssrf.* (advanced) | SSRF Advanced: 19 типов подделки серверных запросов |
| waf.ssti.* | SSI/SSTI Advanced: 7 типов серверных инъекций шаблонов |
| waf.graphql.* | GraphQL: 2 типа атак на схему GraphQL |
DNS
Дашборд Total DNS — агрегация по всем DNS-плагинам. Отдельные дашборды: DNS over UDP, DNS over TCP, DNS over TLS, DNS over HTTP.
| Метрика | Описание |
|---|---|
| dns.tx.queries / dns.rx.responses | Отправленные запросы / полученные ответы |
| dns.tx.bytes / dns.rx.bytes | Объём DNS-данных TX / RX |
| dns.rx.rcode.ok | Ответы с кодом NOERROR |
| dns.rx.rcode.format_error | Ответы с кодом FORMERR |
| dns.rx.rcode.server_failure | Ответы с кодом SERVFAIL |
| dns.rx.rcode.name_error | Ответы с кодом NXDOMAIN |
| dns.rx.rcode.not_implemented | Ответы с кодом NOTIMP |
| dns.rx.rcode.refused | Ответы с кодом REFUSED |
| dns.rx.flags.aa/tc/rd/ra | Флаги DNS-ответов: Authoritative, Truncated, Recursion Desired/Available |
| dns.tls_1_2.* / dns.tls_1_3.* | Метрики DNS over TLS в разрезе версий TLS (пакеты, байты, CC) |
MHDDoS Emulation
Дашборд MHDDoS отображает комбинированные метрики всех активных подплагинов (SYN Flood, UDP Flood, GRE Flood, STRESS и др.) в рамках одной задачи MHDDoS.
PCAP Replay и Динамические приложения
Для сценариев воспроизведения реального трафика доступны отдельные дашборды, которые помогают сравнить отправленный и принятый объем, скорость воспроизведения и состояние сессий.
| Группа метрик | Описание |
|---|---|
| PCAP Replay Stateless | Пакеты, байты и скорость воспроизведения raw-пакетов из PCAP |
| PCAP Replay Stateful | Сессии, пакеты, байты и скорость воспроизведения выбранных TCP/UDP-сессий |
| Applications | Активные пользователи, запущенные/завершенные потоки, неуспешные потоки и общий объем трафика |
CVE Replay и передача файлов
Дашборд CVE выбирается автоматически по комбинации режима (атака / FP) и охвата (первый / все сценарии): cve_replay, cve_replay_all, cve_replay_fp, cve_replay_fp_all. Смысл исходов (completed / blocked_rst / blocked_syn / blocked_timeout / blocked_orphan) и отличие timeout от orphan — в разделе Сетевые уязвимости (CVE).
| Группа метрик | Описание |
|---|---|
| CVE Replay | Попытки воспроизведения и исходы: completed (сценарий дошёл до конца), blocked_rst / blocked_syn / blocked_timeout / blocked_orphan |
| File Transfer | Запросы, ответы, объем переданных файлов и задержки передачи |
| Malware File Transfer | Переданные PTI-файлы, ответы принимающей стороны и результаты проверки средств защиты |
RoCEv2, Elephant Flow и L2 Convergence
| Группа метрик | Описание |
|---|---|
| RoCEv2 | Пакеты, байты, скорость и события перегрузки RoCEv2 |
| Elephant Flow TCP | Длительные TCP-потоки, объем данных, скорость и состояние сессий |
| Elephant Flow UDP | Длительные UDP-потоки, пакеты, байты и скорость передачи |
| L2 Convergence UDP | Потери, восстановление потока и расчет времени сходимости |
IPsec
Для IPsec-сценариев используйте общие дашборды трафика и специализированные панели туннелей. Производительные результаты массовых IPsec-сценариев опубликованы в разделе Benchmarks.
| Группа метрик | Описание |
|---|---|
| Активные туннели | Текущее число поднятых IPsec-туннелей |
| Открытие туннелей | Динамика создания туннелей во времени |
| Трафик через IPsec | Пакеты, байты и скорость передачи внутри туннелей |
| Ошибки и события | Ошибки установления, разрывы и диагностические события туннельных сценариев |
Dual-режим (клиент + сервер)
При одновременном запуске клиентского и серверного плагинов доступны дашборды с суффиксом Dual, объединяющие метрики обеих сторон на одном экране:
| Дашборд | Описание |
|---|---|
| Total Dual | Общие метрики клиента и сервера |
| Total HTTP/TLS Dual | HTTP/TLS агрегация клиент + сервер |
| HTTP/TLS Dual | Детализация HTTP/TLS клиент + сервер |
Служебные метрики
Дополнительные метрики, доступные на общих дашбордах:
| Метрика | Описание |
|---|---|
| arp.rx/tx.packets, arp.rx/tx.bytes | ARP-трафик (автоматический, для резолвинга MAC-адресов) |
| icmp.rx/tx.packets, icmp.rx/tx.bytes | ICMP-трафик (автоматические ответы на ping и др.) |
| kni.rx/tx.packets, kni.rx/tx.bytes | Трафик через KNI-интерфейс (перенаправление в ядро ОС) |
| other.rx | Прочие принятые пакеты, не относящиеся к плагинам |