poc4 wit rust

grafana/README.md

@@ -8,8 +8,8 @@ already available in-memory counters and the last Suricata EVE stats snapshot.
 A scrape does not query SQLite, Redis, RouterOS, the Suricata control socket,
 or analytics endpoints.
 
-The dashboard also uses monotonic TZSP traffic counters exported directly from
-the in-memory flow tracker:
+The dashboard also uses monotonic TZSP traffic counters exported from the Rust
+receiver's 1 Hz telemetry bridge:
 
 ```text
 mikrosuricata_traffic_bytes_total{direction="total|inbound|outbound|internal|external"}
@@ -21,6 +21,11 @@ bits/s. The top of the dashboard therefore shows current total, inbound and
 outbound throughput, packet rate, capture drops, a large throughput chart and
 traffic volume by direction for the selected time range.
 
+Rust receive-path quality is exported separately. In particular,
+`mikrosuricata_tzsp_receiver_kernel_udp_drops_total` is the Linux UDP socket
+drop counter and should stay at zero during high-rate capture tests. The
+dashboard includes it in **Sensor loss & decode errors**.
+
 `/metrics` is protected by an IP/CIDR ACL configured through environment variables.
 The default allows loopback only:
 
@@ -73,3 +78,7 @@ scrape_configs:
 Import `mikrosuricata-prometheus.json` in Grafana and select the Prometheus
 datasource from the dashboard variable. Rate, percentage and ratio panels are
 calculated in PromQL, not by MikroSuricata.
+
+## Rust TZSP data-plane health (0.11.0+)
+
+The receiver now exports both kernel and userspace back-pressure signals. In addition to `mikrosuricata_tzsp_receiver_kernel_udp_drops_total`, watch `mikrosuricata_tzsp_receiver_queue_dropped_datagrams_total`, `mikrosuricata_tzsp_receiver_queue_depth_batches`, `mikrosuricata_tzsp_receiver_queue_capacity_batches` and `mikrosuricata_tzsp_receiver_capture_efficiency_pct`. A small RouterOS kernel socket buffer is expected; loss should be judged by the drop counters, not by buffer size alone.