Metrics and Dashboards
Peresvet ST collects metrics in real time and exports them to ClickHouse. Grafana visualizes the results, with one or more preconfigured dashboards for each plugin type. Dashboards are available from the Peresvet ST web interface while a task is running.
PDF/CSV/HTML report export and task transfer (archive/JSON) are described under Report Export and Task Import.
Reading One-Second Metrics
Peresvet ST metrics show actual traffic behavior over short intervals. On most graphs, a point represents one second of measurements: the number of requests, responses, packets, bytes, or bits that were actually generated, transmitted, received, or processed within that one-second window.
The system does not artificially smooth these graphs over five or ten seconds or draw an idealized target-profile line. Small natural variations may therefore be visible: one second slightly below the target and the next slightly above. This is normal for exact one-second measurements, especially with TCP, HTTP, and many concurrent sessions.
Real network traffic also does not arrive in perfectly identical one-second batches. TCP connections open and close over time; an HTTP request depends on connection readiness and the response; packets are grouped by the NIC and processed by multiple agent cores; and one-second boundaries do not align with individual session boundaries. When events straddle two seconds, adjacent points can differ slightly even though the working-interval average and total traffic volume match the configured profile.
In practice:
- evaluate the plateau after ramp-up and before task shutdown when checking the rate;
- account for CPS and CC: if a task opens 100 new connections per second until it reaches 1,000 active connections, the plateau appears only after ramp-up;
- evaluate the average and total volume over the selected interval, not a single one-second point;
- compare software and hardware metrics: software metrics show what the scenario generated and processed; hardware metrics show what physically crossed the network interface;
- check Drops and loss separately: with zero loss, small one-second fluctuations normally reflect measurement precision rather than a generation problem.
In an HTTP task targeting 10,000 requests per second, the line remains close to the target after ramp-up. Individual points may show 9.9K or slightly more than 10K RPS, but the working average on the plateau matches the target profile.
Figure 24 — HTTP load at 10K RPS: exact one-second values around the target profile
Similar behavior can appear on total packet or bit graphs. If the profile specifies a constant rate but the graph uses actual one-second intervals, a small staircase effect or compensation in the adjacent second is acceptable. Acceptance should focus on the working plateau, average, total traffic volume, and absence of loss.
Figure 25 — Total TX graph: actual one-second intervals without artificial smoothing
Main Metric Groups
Dashboards use several types of indicators. They describe different layers of the same test and should be read together.
| Group | What it shows | How to interpret it |
|---|---|---|
| Requests / Responses | Application operations: HTTP and DNS requests/responses, file-transfer operations, and other L7 events | Verify the application's business profile: how many operations actually completed per second or over the interval |
| Packets | TX/RX network packet count | One application request can produce one or many packets. With TLS, large responses, fragmentation, or retransmission, packet count does not have to match request count |
| Bytes / Bits | Transferred data volume and rate | Evaluate payload and L2/L3 rate. With a fixed packet size, Bits and Packets usually move together |
| L1 / L2 Bits | Rate at different accounting layers | L2 represents Ethernet frame volume; L1 also includes physical line overhead and is therefore used for line-rate evaluation |
| TCP Connections | CPS, active, closed, and pending connections | CPS is the TCP establishment rate; Active connections / CC is current concurrency; Closed shows completion; Pending shows connections being established |
| Drops / Loss | Loss, discarded packets, and RX/TX errors | Evaluate drops/loss after completion. During a run, short-lived loss in Total Statistics can be an artifact of metrics arriving from agents at different times; see below |
| Generated / Software | Scenario counters within the agent | Show how much traffic the scenario generated, processed, and accounted for at the application or network-stack layer |
| Hardware / Physical | Network-interface hardware statistics | Show actual physical-port traffic: line rate, L1/L2 bits, hardware packet counts, and interface errors |
Software and hardware metrics complement rather than replace each other. Software metrics validate scenario logic: requests, responses, sessions, applications, response codes, latency, and errors. Hardware metrics confirm that traffic actually left the port and was received by the NIC. First confirm that the scenario reached its plateau, then compare software and hardware, and finally evaluate drops/loss.
Personalized Dashboards
Personalized dashboards add specialized views for particular test scenarios to the standard task metrics. Each dashboard supports a separate analysis objective and can be enabled independently.
They are disabled by default because the agent collects extra traffic detail for them. Before starting a task, an administrator must open Settings → Dashboards, click Select Dashboards, choose the required dashboards, and apply the change. Additional metrics are collected from the next task run; they are not calculated retroactively for a running or completed task.
Once enabled, the selected dashboards appear on the Metrics tab of applicable tasks.
Responder Load Balancing
Responder Load Balancing is intended for testing load balancers, DSR/IP-IP designs, and other solutions that distribute inbound traffic among multiple server IP addresses. It adds a per-responder view to the total task metrics and verifies not only aggregate rate but also the actual uniformity of distribution.
The dashboard groups metrics by responder IP and shows traffic entering the responder side—what the client sent to the servers. The reverse flow, which servers transmit and the client receives, appears on general dashboards as Server TX / Client RX and is not included in this per-responder RX view. With small requests and large responses, Client RX can therefore be much greater than responder RX. These are different directions of one exchange, not an error.
The dashboard contains:
| Block | What it shows |
|---|---|
| Active / total responders | IP addresses that received inbound traffic and the total observed group size (Responder Size) |
| No inbound traffic | Responders that received no traffic during the selected interval |
| Maximum TCP CPS deviation | Largest deviation of one responder's TCP establishment rate from the group average |
| Top 10 underloaded / overloaded | IP addresses with the greatest negative and positive deviations from the average distribution |
| Selected responder details | TCP CPS, TCP CC, pending/closed connections, and inbound bits/packets for selected IP addresses |
Figure 25a — Load-distribution summary by responder IP address
The dashboard analyzes a group of up to 256 responder IP addresses in one test profile. With more addresses, total task metrics continue to show aggregate traffic, but Responder Size and per-IP distribution details may be incomplete.
Total Metrics
The Total dashboard and Total Statistics section show aggregate task indicators: sent, received, and lost packets/bits in each direction between agents.
| Metric | Description |
|---|---|
| total.rx.packets / total.tx.packets | Total received/transmitted packets |
| total.rx.bytes / total.tx.bytes | Total received/transmitted bytes |
| total.tx.drop | Packets discarded during transmission |
| total.pkt.lost | Lost packets |
| total.rx.bad | Invalid received packets |
| total.tx.l1_bits / total.rx.l1_bits | TX/RX L1 bit rate, including inter-frame gaps and preambles |
| total.tx.line_rate / total.rx.line_rate | TX/RX line utilization (%) |
| total.cpu_usage | Processing-core CPU utilization |
| total.tos.rx | Received packets analyzed by ToS |
| total.rx.imissed | Packets missed by the NIC because a queue overflowed |
| total.rx.ierrors | NIC-level receive errors |
Total Statistics: Loss During Execution
The Total Statistics (Packets) and Total Statistics (Bits) tables calculate loss as the difference between transmission on one side and reception on the other, grouped by the agent-to-agent direction and interfaces.
Agents write metrics to ClickHouse independently and do not synchronize batch-send times. While a task is running, a dashboard can briefly lag: TX on one agent has updated while RX on the other has not, or vice versa. Lost or Loss (%) can then become nonzero for seconds or minutes before decreasing or returning to zero when the lagging side catches up. Visibility depends on the traffic rate and when the Metrics tab is opened.
This is most visible when the task uses two separate agents. When both directions use one agent with two interfaces, the skew is generally smaller, but a brief imbalance is still possible.
For acceptance, inspect Total Statistics after the task has completed fully and stably and both agents have written final metrics. Final loss on a stopped task is the primary reference; transient nonzero loss during a run alone does not prove that the DUT dropped packets.
Agent Anomalies
The Agent Anomalies table on Total (Dual) shows packets and events discarded by the NIC or software stack on a particular agent. These are local diagnostic counters. They are not the same as client-to-server loss in Total Statistics and do not by themselves prove that the DUT dropped packets.
Values are counter increases during the selected dashboard interval, grouped by agent and interface. Zero means that the counter did not increase during that interval.
| Column | Meaning |
|---|---|
| Agent | Agent on which the anomaly was recorded |
| Interface | Agent network interface associated with the counter |
| TX drop | Packets prepared by the software stack but not placed in the transmit queue. Growth usually means that the agent or NIC cannot transmit generated traffic fast enough |
| RX missed | Packets missed by the NIC before delivery to the software stack, for example because an RX queue overflowed. Often indicates that the agent cannot drain RX fast enough at the current load |
| RX discards | Internal NIC-side discards. On Mellanox, this is rx_phy_discard_packets, which can grow because of limits in the card's internal pipeline or PCIe exchange |
| RX errors | Receive errors reported by the NIC or driver |
| RX bad | Packets that reached the software stack but were considered invalid, for example because of a bad checksum, invalid format, or parsing/decapsulation error |
| RX no_ws | No matching task worker context was found for the received packet. Check protocol, addresses, interface, configuration, and routing to the correct processing queue |
| RX nombuf | The NIC could not obtain a free buffer for another received packet. Growth indicates too few packet buffers or delayed release under high load |
| TCP drop | Total packets discarded by the agent software TCP stack, including the adjacent reasons and other TCP drop causes |
| Bad seq server | The client agent received a server packet whose TCP sequence/ACK values did not match the located client socket state |
| No socket client | The client agent received a packet for the configured address range but found no active client TCP socket for the connection. Causes include a late packet after closure, an unexpected IP/port combination, delivery to the wrong processing context, or state desynchronization under load |
| SYN/ACK bad ACK | The client received a SYN/ACK whose acknowledgment number did not correspond to its SYN; the response cannot complete the handshake and is dropped |
| Bad seq client | The server agent received a client packet whose TCP sequence/ACK values did not match the located server socket state |
| Total | Sum of TX drop, hardware/general RX anomalies, and TCP drop. Individual TCP drop reason columns are not added again, so a single TCP drop is not counted twice |
HTTP / TLS
Total HTTP/TLS aggregates all HTTP plugins. HTTP/TLS provides per-plugin details.
| Metric | Description |
|---|---|
| http_1_1.tx.requests / http_1_1.rx.responses | Sent requests / received responses (HTTP/1.1) |
| http_1_1.tx.bytes / http_1_1.rx.bytes | TX/RX data volume |
| http_1_1.code.1xx–5xx | HTTP response code distribution (1xx, 2xx, 3xx, 4xx, 5xx) |
| http_1_1.ttfb | Average TTFB from HTTP/1.1 request transmission until the client processes the first response byte |
| http_1_1.ttlb | Average TTLB from HTTP/1.1 request transmission until the client processes the complete response |
| http_1_1.wire_ttfb | Wire TTFB from HTTP/1.1 request transmission until the client NIC timestamps the first response byte |
| http_1_1.method.get/post/put/patch/delete | Requests by HTTP method |
| http_2.tx.requests / http_2.rx.responses | Sent requests / received responses (HTTP/2) |
| http_2.code.1xx–5xx | HTTP/2 response code distribution |
| http_2.ttfb / http_2.ttlb | Average time to the first byte / complete HTTP/2 response |
| http_2.streams.opened/closed/reseted | Opened/closed/reset HTTP/2 streams |
| tcp.cps | TCP Connections Per Second: new connections per second |
| tcp.cc | TCP Concurrent Connections: current active connections |
| tcp.hs_avg_delay | Average handshake delay from SYN transmission until the client software TCP stack processes SYN/ACK |
| tcp.hs_wire_avg_delay | Wire RTT from SYN transmission until the client NIC timestamps SYN/ACK |
| TCP Data RTT Avg | Average time from transmission of a selected data-bearing TCP segment until its acknowledging ACK; calculated from exact values, excluding retransmissions |
| TCP Data RTT P50 / P95 / P99 | Data RTT percentiles rounded up to the nearest bucket boundary; for example, 15 ms means greater than 10 ms and at most 15 ms |
| TCP Wire Data RTT Avg / P50 / P95 / P99 | The same measurement with a hardware timestamp for the incoming ACK at the client NIC |
| TCP Data RTT Jitter | Average change in Data RTT between adjacent measurements |
| TCP Data RTT Samples | Completed measurements and measurements excluded because of retransmission |
| tls_1_2.hs_avg_delay / tls_1_3.hs_avg_delay | Average TLS session establishment delay after the TCP handshake completes |
| tls_1_2.* / tls_1_3.* | Other TLS 1.2/1.3 metrics: packets, bytes, CPS, CC, and Client/Server Hello |
Latency metrics cover the full path observed by the client agent: traversal through the DUT, server-agent processing, and return traffic. TCP Data RTT runs from queuing a selected segment for transmission until its acknowledging ACK is received. Wire Data RTT hardware-timestamps ACK reception at the client NIC but still includes transmit-queue wait on the server agent.
At close to 100% line utilization, an ACK can wait behind data packets, increasing P95/P99 even without loss or retransmission. When comparing DUT impact, make sure the agents are not bottlenecks and leave 5–10% L1 headroom.
Wire RTT, Wire Data RTT, and Wire TTFB require compatible hardware and are available only on Peresvet ST appliances. They are unavailable on virtual machines and other deployment types.
Latency Measurement (IP/UDP)
The Latency Measurement (IP/UDP) dashboard shows results from the plugin of the same name. Latency is calculated on the client agent from server-side responses.
| Panel / metric | Description |
|---|---|
| CLIENT | UDP RTT — Avg RTT | Average time from measured UDP request transmission until the client agent receives the response |
| CLIENT | UDP RTT — P50 / P95 / P99 RTT | RTT percentiles rounded up to the nearest bucket boundary |
| CLIENT | UDP Wire RTT — Wire RTT | Average control-flow RTT with hardware response timestamping at the client NIC |
| CLIENT | UDP Wire RTT — P50 / P95 / P99 Wire RTT | Control-flow Wire RTT percentiles with hardware response timestamping |
| CLIENT | UDP RTT Jitter — Avg RTT jitter | Average absolute RTT change between adjacent measured responses |
| CLIENT | UDP RTT Jitter — Wire RTT jitter | The same change for Wire RTT |
| CLIENT | Measured samples — RTT samples/s | Responses per second included in RTT calculation |
| CLIENT | Measured samples — Wire RTT samples/s | Control-flow responses per second with a hardware timestamp |
| CLIENT | UDP requests and responses | All sent UDP requests and received responses; lines can temporarily differ at a one-second boundary |
Packets are sent at the configured rate, while RTT and jitter use a uniform sample. The measured sample count can therefore be lower than the request count. RTT includes both directions through the DUT and response processing by the server agent.
UDP RTT runs from queuing a selected UDP request for transmission until the client agent receives its response. Wire RTT hardware-timestamps response reception at the client NIC but still includes response transmit-queue wait on the server agent.
At close to 100% line utilization, a UDP response can wait behind other packets, increasing P95/P99 even without loss. When comparing DUT impact, make sure the agents are not bottlenecks and leave 5–10% L1 headroom.
Wire RTT and Wire RTT jitter require compatible hardware and are available only on Peresvet ST appliances. They are unavailable on virtual machines and other deployment types.
TCP Flood (SYN / SYN-ACK / ACK / RST / RST-ACK / FIN / FIN-ACK / PSH / PSH-ACK / Xmas)
Total TCP aggregates all TCP flood plugins. Each flood type also has its own dashboard, such as TCP SYN, TCP ACK, or TCP Xmas.
| Metric | Description |
|---|---|
| tcp.tx.flags.syn / tcp.rx.flags.syn | Sent/received SYN packets |
| tcp.tx.flags.syn_ack / tcp.rx.flags.syn_ack | Sent/received SYN-ACK packets |
| tcp.tx.flags.ack / tcp.rx.flags.ack | Sent/received ACK packets |
| tcp.tx.flags.rst / tcp.rx.flags.rst | Sent/received RST packets |
| tcp.tx.flags.rst_ack / tcp.rx.flags.rst_ack | Sent/received RST-ACK packets |
| tcp.tx.flags.fin / tcp.rx.flags.fin | Sent/received FIN packets |
| tcp.tx.flags.fin_ack / tcp.rx.flags.fin_ack | Sent/received FIN-ACK packets |
| tcp.tx.flags.psh / tcp.rx.flags.psh | Sent/received PSH packets |
| tcp.tx.flags.psh_ack / tcp.rx.flags.psh_ack | Sent/received PSH-ACK packets |
| tcp.tx.flags.xmas / tcp.rx.flags.xmas | Sent/received Xmas packets (all flags) |
| tcp.tx.packets / tcp.rx.packets | Total TX/RX TCP packets |
| tcp.tx.bytes / tcp.rx.bytes | TX/RX TCP data volume |
UDP Flood
Total UDP is the aggregate dashboard; UDP provides details.
| Metric | Description |
|---|---|
| udp.tx.packets / udp.rx.packets | Sent/received UDP packets |
| udp.tx.bytes / udp.rx.bytes | TX/RX UDP data volume |
| udp.rt | UDP round-trip response time |
| udp.drop | Lost UDP packets |
Fuzzing (L3-L7)
The Fuzzing (L3-L7) dashboard shows the results of enabled UDP/TCP Fuzzing modules and flow scenarios. It verifies the actual transmission rate, traffic volume, and L4 session state during a test.
| Dashboard block | What it shows |
|---|---|
| L3-L4 Fuzzing overview | Task summary and Fuzzing profile activity over the selected interval |
| UDP: sent packets | Separate lines for enabled modules: invalid checksum, TTL, DSCP/ECN, IP ID, Payload Data, and UDP Flow |
| TCP: sent packets | Separate lines for enabled modules: PSH/ACK, invalid checksum, SEQ, MSS, Window Scale, TCP window, Payload Data, and TCP Flow |
| UDP: sent bytes / bits | UDP traffic volume and rate in bytes/bits |
| TCP: sent bytes / bits | TCP traffic volume and rate in bytes/bits |
| L4 sessions / flow | TCP session and UDP flow state when flow modules are enabled |
| TCP Connections | TCP session creation, activity, and closure |
| UDP Flow Sessions | UDP flow count and activity |
When several Fuzzing modules are enabled, compare UDP: sent packets and TCP: sent packets with the configured Packets per Second budget. This verifies that load was distributed among the selected modules as expected.
GRE Flood
Total GRE is the aggregate dashboard; GRE provides details.
| Metric | Description |
|---|---|
| gre.tx.packets / gre.rx.packets | Sent/received GRE packets |
| gre.tx.bytes / gre.rx.bytes | TX/RX GRE data volume |
DNS Flood
Total DNS Flood is the aggregate dashboard; DNS Flood provides details.
| Metric | Description |
|---|---|
| dns_flood.tx.packets / dns_flood.rx.packets | Sent/received DNS Flood packets |
| dns_flood.tx.bytes / dns_flood.rx.bytes | TX/RX DNS Flood data volume |
ICMP / Ping / Fragmentation / Amplification
| Dashboard key | Plugin |
|---|---|
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
The compromised_host dashboard shows C2 sessions, steps, timeouts, and beacons.
DHCP Flood (Legacy)
Total DHCP Flood is the aggregate dashboard; DHCP Flood provides details.
| Metric | Description |
|---|---|
| dhcp_flood.tx.packets / dhcp_flood.rx.packets | Sent/received DHCP Flood packets |
| dhcp_flood.tx.bytes / dhcp_flood.rx.bytes | TX/RX DHCP Flood data volume |
WAF
The WAF dashboard shows Web Application Firewall test results: requests sent in each attack category.
| Metric group | Description |
|---|---|
| waf.broken_access_control, waf.injection.*, waf.xss.*, waf.ssrf, and others | Basic test: one metric per attack type (18 categories) |
| waf.sqli.* | SQLi Advanced: 50 SQL injection types |
| waf.xxe.* | XXE Advanced: four XML parser attack types |
| waf.cmdi.* | Command Injection Advanced: 18 OS command types |
| waf.fi.* | File Injection Advanced: eight file-inclusion types |
| waf.pt.* | Path Traversal Advanced: 17 traversal types |
| waf.unc.* | UNC Path: four UNC-path attack types |
| waf.rce.* | RCE Advanced: six remote-code-execution types |
| waf.xss.* (advanced) | XSS Advanced: 19 cross-site scripting types |
| waf.ssrf.* (advanced) | SSRF Advanced: 19 server-side request forgery types |
| waf.ssti.* | SSI/SSTI Advanced: seven server-side template injection types |
| waf.graphql.* | GraphQL: two schema attack types |
DNS
Total DNS aggregates all DNS plugins. Separate dashboards are available for DNS over UDP, DNS over TCP, DNS over TLS, and DNS over HTTP.
| Metric | Description |
|---|---|
| dns.tx.queries / dns.rx.responses | Sent queries / received responses |
| dns.tx.bytes / dns.rx.bytes | TX/RX DNS data volume |
| dns.rx.rcode.ok | NOERROR responses |
| dns.rx.rcode.format_error | FORMERR responses |
| dns.rx.rcode.server_failure | SERVFAIL responses |
| dns.rx.rcode.name_error | NXDOMAIN responses |
| dns.rx.rcode.not_implemented | NOTIMP responses |
| dns.rx.rcode.refused | REFUSED responses |
| dns.rx.flags.aa/tc/rd/ra | DNS response flags: Authoritative, Truncated, Recursion Desired/Available |
| dns.tls_1_2.* / dns.tls_1_3.* | DNS-over-TLS metrics by TLS version: packets, bytes, and CC |
MHDDoS Emulation
The MHDDoS dashboard combines metrics for all active subplugins (SYN Flood, UDP Flood, GRE Flood, STRESS, and more) in one MHDDoS task.
PCAP Replay and Dynamic Applications
Dedicated dashboards for replaying real traffic compare sent and received volume, replay rate, and session state.
| Metric group | Description |
|---|---|
| PCAP Replay Stateless | Packets, bytes, and replay rate of raw PCAP packets |
| PCAP Replay Stateful | Sessions, packets, bytes, and replay rate of selected TCP/UDP sessions |
| Applications | Active users, started/completed flows, failed flows, and total traffic volume |
CVE Replay and File Transfer
The CVE dashboard is selected automatically from the combination of mode (attack/FP) and coverage (first/all scenarios): cve_replay, cve_replay_all, cve_replay_fp, or cve_replay_fp_all. Outcome semantics (completed, blocked_rst, blocked_syn, blocked_timeout, blocked_orphan) and the distinction between timeout and orphan are described under Network Vulnerabilities (CVE).
| Metric group | Description |
|---|---|
| CVE Replay | Replay attempts and outcomes: completed (scenario reached its end), blocked_rst, blocked_syn, blocked_timeout, and blocked_orphan |
| File Transfer | Requests, responses, transferred file volume, and transfer latency |
| Malware File Transfer | Transferred PTI files, receiver responses, and security-system inspection results |
RoCEv2, Elephant Flow, and L2 Convergence
| Metric group | Description |
|---|---|
| RoCEv2 | RoCEv2 packets, bytes, rate, and congestion events |
| Elephant Flow TCP | Long-lived TCP flows, data volume, rate, and session state |
| Elephant Flow UDP | Long-lived UDP flows, packets, bytes, and rate |
| L2 Convergence UDP | Loss, flow recovery, and convergence-time calculation |
IPsec
For IPsec scenarios, use the general traffic dashboards and specialized tunnel panels. Performance results for bulk IPsec scenarios are published under Benchmarks.
| Metric group | Description |
|---|---|
| Active tunnels | Current established IPsec tunnel count |
| Tunnel establishment | Tunnel creation over time |
| Traffic through IPsec | Packets, bytes, and rate within tunnels |
| Errors and events | Establishment errors, disconnects, and tunnel-scenario diagnostic events |
Dual Mode (Client + Server)
When client and server plugins run together, Dual dashboards combine metrics from both sides:
| Dashboard | Description |
|---|---|
| Total Dual | General client and server metrics |
| Total HTTP/TLS Dual | Combined client + server HTTP/TLS aggregate |
| HTTP/TLS Dual | Combined client + server HTTP/TLS details |
Service Metrics
Additional metrics on general dashboards:
| Metric | Description |
|---|---|
| arp.rx/tx.packets, arp.rx/tx.bytes | Automatic ARP traffic used to resolve MAC addresses |
| icmp.rx/tx.packets, icmp.rx/tx.bytes | ICMP traffic, including automatic ping replies |
| kni.rx/tx.packets, kni.rx/tx.bytes | Traffic through the KNI interface, redirected to the OS kernel |
| other.rx | Other received packets unrelated to plugins |