Kiểm thử eBPF network observability: coverage, overhead và mất sự kiện

Một nền tảng eBPF observability có thể thu được flow record nhưng vẫn thiếu short-lived connection, traffic bypass qua datapath khác hoặc sự kiện bị drop trước khi export. Vì vậy câu hỏi đầu tiên là coverage: trong tập sự kiện ground truth, tỷ lệ nào được quan sát và trường dữ liệu nào chính xác. Câu hỏi thứ hai là fidelity: timestamp, tuple, bytes, direction, process/container identity và verdict có phản ánh đúng thực tế không.

Câu hỏi thứ ba là chi phí. Khi bật probe, throughput ứng dụng giảm bao nhiêu, latency p99 thay đổi ra sao, CPU/memory và scheduler pressure tăng thế nào. Cuối cùng là vận hành: agent restart, collector backpressure, node pressure và kernel upgrade có làm mất sự kiện hoặc tạo khoảng trống khó phát hiện không.

Topology nên gồm ít nhất hai node/workload, load generator, collector/backend và một đường capture độc lập. Trong Kubernetes, cần phủ pod-to-pod cùng node, khác node, pod-to-service, ingress/egress và host-network nếu có. Với VM hoặc bare metal, ghi rõ namespace, interface, overlay, offload và nơi chương trình eBPF attach.

Ground truth không nên phụ thuộc cùng pipeline eBPF đang kiểm thử. Có thể kết hợp counter từ traffic generator, packet capture tại TAP/SPAN hoặc virtual mirror, application transaction log và socket statistics. Packet capture cũng có thể mất gói, nên phải kiểm tra drop counter và capacity của capture path. Một event ID ở application layer giúp nối transaction, packet và flow record mà không cần suy luận hoàn toàn từ 5-tuple.

Hồ sơ chạy phải ghi kernel version/config, distribution, CPU architecture, container runtime, CNI/datapath, eBPF agent version, attach point và map/buffer sizing. XDP, TC, cgroup, tracepoint, kprobe và socket hooks quan sát ở các lớp khác nhau; không thể suy rộng coverage của một hook sang toàn bộ mạng. Offload, GRO/GSO/TSO và encryption cũng làm hình dạng packet nhìn thấy tại hook khác với wire.

Traffic profile cần có long flow và short flow, TCP/UDP, connection success/failure, retransmission, reset, DNS, IPv4/IPv6, encrypted traffic và burst. Giữ frame size, connection rate, concurrency, throughput và duration. Đặc biệt phải tăng event rate độc lập với byte rate: hàng triệu flow nhỏ có thể làm pipeline sự kiện quá tải dù bandwidth thấp.

• Nhóm biến: Kernel/host · Cần khóa: version, config, arch, offload · Vì sao: Ảnh hưởng hook và verifier/runtime
• Nhóm biến: Datapath · Cần khóa: CNI, overlay, encryption, attach point · Vì sao: Quyết định traffic nào nhìn thấy
• Nhóm biến: Agent · Cần khóa: version, maps, ring buffer, sampling · Vì sao: Ảnh hưởng event loss và trường dữ liệu
• Nhóm biến: Export · Cần khóa: batch, queue, collector capacity · Vì sao: Có thể tạo loss ngoài kernel
• Nhóm biến: Traffic · Cần khóa: CPS, flows, bytes/s, protocol, burst · Vì sao: Tách event rate khỏi throughput
• Nhóm biến: Ground truth · Cần khóa: capture point, drop counter, clock · Vì sao: Đảm bảo đối chiếu đáng tin

Đầu tiên chạy workload khi agent chưa bật hoặc ở cấu hình tối thiểu, ghi throughput, transaction rate, latency p50/p95/p99, CPU system/user, memory, context switch, softirq, network drop và application error. Warm-up đủ lâu để JIT, cache, connection pool và autoscaling ổn định. Baseline phải lặp lại để biết nhiễu tự nhiên trước khi quy chênh lệch cho eBPF.

Sau đó bật từng nhóm chức năng theo bậc: flow only, process identity, L7 parsing, policy verdict, DNS hoặc full export. Không bật tất cả một lần vì sẽ không xác định feature nào tạo overhead. Mỗi bậc dùng đúng traffic profile, affinity và resource limit; lưu cả agent metrics như lost events, map pressure, queue depth và export retry.

Coverage có thể tính theo connection, transaction, flow hoặc packet tùy mục tiêu. Với observability, nên báo recall của sự kiện quan trọng: số connection/transaction ground truth được telemetry ghi nhận chia tổng số thật. Precision cũng cần thiết nếu agent sinh duplicate hoặc gán sai workload. Field accuracy đo riêng cho source/destination, port, protocol, bytes, direction, identity, verdict và timestamp.

Overhead phải được báo bằng chênh lệch tương đối và tuyệt đối so với baseline: CPU cores hoặc %, memory resident, throughput, latency percentile, connection setup time và error rate. Không chỉ lấy average; overhead thường rõ ở p99 hoặc burst. Event loss cần đo tại từng stage nếu có counter: kernel/perf/ring buffer, agent queue, exporter và collector ingest.

• KPI: Event recall · Công thức/đo: matched events / ground-truth events · Pass/fail cần chốt: Theo loại sự kiện quan trọng
• KPI: Field accuracy · Công thức/đo: trường khớp / trường đối chiếu · Pass/fail cần chốt: Tuple, identity, bytes, timestamp
• KPI: Duplicate rate · Công thức/đo: duplicate / exported events · Pass/fail cần chốt: Ngưỡng theo pipeline
• KPI: Event loss · Công thức/đo: counter drop theo stage · Pass/fail cần chốt: Không che loss; ngưỡng theo use case
• KPI: CPU overhead · Công thức/đo: enabled − baseline · Pass/fail cần chốt: Theo node budget
• KPI: Latency impact · Công thức/đo: p95/p99 enabled so với baseline · Pass/fail cần chốt: Theo SLO ứng dụng
• KPI: Recovery gap · Công thức/đo: thời gian thiếu telemetry khi restart · Pass/fail cần chốt: Theo mục tiêu vận hành

Không có một cấu hình tối ưu cho mọi use case. NDR cần fidelity packet/flow và timestamp; troubleshooting Kubernetes cần workload identity và DNS/L7 context; capacity monitoring có thể chấp nhận aggregation. Quyết định phải dựa trên bằng chứng và budget tài nguyên.

Nếu không thể đạt coverage và overhead đồng thời, có thể phân tầng: telemetry eBPF rộng, packet capture có chọn lọc tại điểm trọng yếu, active test định kỳ và log ứng dụng. Không nên tuyên bố eBPF thay thế hoàn toàn TAP/packet broker hoặc ngược lại; mỗi nguồn trả lời câu hỏi khác nhau.

• Use case: Sự cố kết nối · Coverage ưu tiên: Short flow, reset, DNS · Overhead chấp nhận: Thấp–vừa · Kiểm chứng chính: Recall theo transaction
• Use case: Security detection · Coverage ưu tiên: Process, verdict, direction · Overhead chấp nhận: Theo risk budget · Kiểm chứng chính: Precision/recall và mất event
• Use case: Performance · Coverage ưu tiên: Bytes, RTT, retransmission · Overhead chấp nhận: Rất thấp · Kiểm chứng chính: So với generator/PCAP
• Use case: Inventory/service map · Coverage ưu tiên: Identity và dependency · Overhead chấp nhận: Có thể aggregation · Kiểm chứng chính: Độ đúng node/edge
• Use case: Incident forensics · Coverage ưu tiên: Timestamp, sequence, retention · Overhead chấp nhận: Cần dung lượng cao · Kiểm chứng chính: Khoảng trống và chain of custody

Fault injection không được làm trên production nếu chưa có phạm vi và rollback. Trong lab, mỗi fault phải có timestamp, duration và giới hạn tài nguyên. Khi collector backpressure, cần quan sát agent drop hay lưu đệm; việc dashboard tiếp tục hiển thị không chứng minh dữ liệu mới vẫn đầy đủ.

• Lưu inventory kernel, CNI/runtime, agent, collector và resource limit.
• Kiểm tra time sync, capture drop counter và ID đối chiếu.
• Chạy baseline không bật chức năng quan sát mục tiêu, lặp tối thiểu theo kế hoạch.
• Bật từng feature; đo application KPI và system overhead.
• Chạy ma trận long/short flow, TCP/UDP, DNS, IPv4/IPv6, cùng/khác node.
• Tăng connection rate và burst cho đến khi xuất hiện lost-event hoặc đạt giới hạn an toàn.
• Gây collector slowdown, network interruption và agent restart; đo queue, loss, recovery gap.
• Tạo node CPU/memory pressure có kiểm soát; xác minh telemetry không im lặng.
• Nâng hoặc đổi một kernel/CNI trong lab; chạy regression coverage.
• Đối chiếu ground truth, báo recall/precision, overhead và raw counter.

PCAP tại một interface không phản ánh mọi hook, đặc biệt khi offload hoặc overlay thay đổi packet. Application log có thể bỏ transaction trước khi gửi mạng. Vì thế ground truth nên đa nguồn và phải ghi bất định. Field bytes trong flow telemetry có thể có semantics khác wire bytes; chỉ so sánh khi đã thống nhất lớp và overhead.

Kết quả chỉ áp dụng cho kernel, CNI, agent, hook, collector và workload đã chạy. Thay kernel minor, bật encryption, đổi runtime hoặc chuyển workload sang host network có thể thay coverage. Tính năng L7, sampling, retention và map size cần kiểm tra đúng phiên bản; không suy diễn từ dự án eBPF nói chung sang một sản phẩm cụ thể.

• eBPF: Cơ chế chạy chương trình được kiểm tra trong kernel tại các hook xác định.
• Verifier: Thành phần kiểm tra chương trình eBPF trước khi cho phép nạp.
• Map: Cấu trúc dữ liệu chia sẻ giữa chương trình eBPF và user space.
• Ring buffer: Kênh chuyển sự kiện từ kernel ra user space; có thể drop khi quá tải.
• XDP: Hook sớm trên receive path, phù hợp xử lý packet hiệu năng cao.
• TC: Hook traffic control trên ingress/egress, có ngữ cảnh khác XDP.
• Ground truth: Nguồn đối chiếu độc lập dùng đánh giá coverage/fidelity.
• Telemetry gap: Khoảng thời gian hoặc phạm vi sự kiện không được ghi nhận.