Kiểm thử gNMI streaming telemetry: subscription, timestamp, backpressure và collector failover

gNMI là giao diện quản lý mạng dựa trên gRPC, hỗ trợ Capabilities, Get, Set và Subscribe. Trong bài toán visibility, trọng tâm là thiết bị có quảng bá đúng model/path không; update có đúng giá trị và timestamp không; collector có nhận đủ dưới tải không; và hành vi khi stream hoặc collector lỗi có phù hợp thiết kế không.

Không nên bắt đầu bằng mục tiêu mơ hồ như “thu telemetry real time”. Hãy chốt path, tần suất hoặc điều kiện phát sinh update, độ trễ cho phép, quy mô target/subscription, retention và bằng chứng đối chiếu. “Real time” phải được thay bằng SLO đo được.

Topology tối thiểu gồm thiết bị hoặc emulator gNMI, traffic generator tạo thay đổi counter/state, bộ mô phỏng latency/loss, primary và secondary collector, message bus/time-series database và nguồn clock chung. Lấy CLI/API hoặc packet counter của traffic generator làm ground truth độc lập; không dùng chính collector cần kiểm để chứng minh collector đúng.

Khóa OS/version, OpenConfig hoặc native model revision, encoding, gRPC/TLS, certificate, path prefix, subscription list và collector build. Đồng bộ clock bằng nguồn được giám sát; ghi clock offset trước và sau mỗi run. Nếu timestamp của target và collector chưa có cùng chuẩn, chỉ được kết luận arrival delay chứ không gọi đó là telemetry latency.

Biến protocol gồm RPC, subscription mode, stream mode, sample interval, suppress_redundant, heartbeat interval, updates_only, encoding và path wildcard. Biến target gồm số interface, số path, tốc độ counter, CPU, queue và giới hạn concurrent RPC. Biến collector gồm worker/thread, receive window, queue, batch size, retry, deduplication và write latency.

Biến mạng gồm RTT, jitter, packet loss, reset, TLS reconnect/handshake (không giả định TLS 1.3 hỗ trợ renegotiation) và outage. Biến downstream gồm broker unavailable, database slow, disk full và schema rejection. Thay đổi một nhóm mỗi lần; nếu đồng thời tăng target, path và sample rate thì khó xác định bottleneck.

Mỗi update nên được nối bằng target, path, sequence logic, source timestamp, receive timestamp và persisted timestamp. Nếu implementation không có sequence number, tạo sự kiện có dấu vết biết trước—ví dụ flap interface theo lịch hoặc tăng counter theo profile—để phát hiện thiếu/nhân đôi.

Capabilities không trả danh sách đầy đủ các path được hỗ trợ. gNMI cho phép gộp update khi client chậm; trường duplicates có thể báo số thay đổi đã bị gộp. Vì vậy ON_CHANGE không nên được coi là nhật ký không mất mọi transition. Với ONCE/POLL, kiểm sync_response và trường updates_only trước khi kết luận snapshot thiếu.

Không gộp “không nhận update” thành một lỗi duy nhất. Tách target không phát, transport gián đoạn, collector drop, schema reject và storage lag. Pass/fail phải có ngân sách mất dữ liệu và thời gian phục hồi cụ thể.

• KPI: Path/schema coverage · Cách đo: Đối chiếu model/encoding từ Capabilities; kiểm từng path bằng Get/Subscribe · Bằng chứng: Model, version, path map
• KPI: Update completeness · Cách đo: Ground truth so với collector · Bằng chứng: Expected/received/missing
• KPI: Freshness · Cách đo: Receive trừ source timestamp · Bằng chứng: p50/p95/p99, clock offset
• KPI: Persist latency · Cách đo: Persisted trừ receive · Bằng chứng: Queue và DB metrics
• KPI: Duplicate/out-of-order · Cách đo: Event ID hoặc state transition · Bằng chứng: Raw stream + pipeline log
• KPI: Backpressure · Cách đo: Queue depth, blocked stream, drop · Bằng chứng: gRPC/collector telemetry
• KPI: Recovery · Cách đo: Fault clear đến SLO ổn định · Bằng chứng: Timeline và data gap

TARGET_DEFINED không nên được coi là “tự động đúng”. Cần ghi target đã chọn SAMPLE hay ON_CHANGE cho từng path và kiểm lại sau upgrade. Với counter tốc độ cao, sampling quá thưa có thể giữ xu hướng nhưng làm mất burst; với state, polling quá thưa có thể bỏ transition ngắn.

• Trường hợp: ONCE · Kỳ vọng: Snapshot rồi đóng stream · Cần kiểm: Đủ path, trạng thái kết thúc
• Trường hợp: POLL · Kỳ vọng: Snapshot theo yêu cầu poll · Cần kiểm: Không trộn chu kỳ, latency poll
• Trường hợp: STREAM/SAMPLE · Kỳ vọng: Update theo interval · Cần kiểm: Interval error, suppress/heartbeat
• Trường hợp: STREAM/ON_CHANGE · Kỳ vọng: Update khi state đổi theo khả năng target · Cần kiểm: Đối chiếu transition; ghi nhận coalescing và trường duplicates
• Trường hợp: TARGET_DEFINED · Kỳ vọng: Target chọn hành vi · Cần kiểm: Mapping phải được ghi rõ
• Trường hợp: Collector chậm · Kỳ vọng: Backpressure có kiểm soát · Cần kiểm: Drop, queue, target impact
• Trường hợp: Collector restart · Kỳ vọng: Reconnect/resubscribe · Cần kiểm: Gap, duplicate, state rebuild
• Trường hợp: DB unavailable · Kỳ vọng: Buffer hoặc fail rõ · Cần kiểm: Data loss và recovery policy

Pha A gọi Capabilities, xác minh model/encoding và chạy Get làm snapshot. Pha B kiểm ONCE và POLL trên bộ path nhỏ. Pha C chạy STREAM ở baseline, tạo counter/state transition biết trước, so source–receive–persist. Pha D tăng dần target, path và update rate độc lập để tìm knee point.

Pha E chèn loss, RTT, reset TLS, target reboot, collector restart và downstream slow. Pha F kiểm failover giữa hai collector: subscription ownership, duplicate, gap và state rebuild. Pha G nâng cấp một thành phần rồi regression toàn bộ path bắt buộc; không chỉ xác nhận kết nối TCP/gRPC.

• Lưu model, revision, encoding và danh sách path bắt buộc.
• Chốt subscription/stream mode, sample và heartbeat cho từng path.
• Đo clock offset; lưu source, receive và persisted timestamp.
• Tạo ground truth bằng traffic/state transition có lịch.
• Tăng target, path và rate theo từng trục riêng.
• Theo dõi CPU/queue ở target, collector, broker và database.
• Chèn collector crash, network reset và downstream outage.
• Báo missing, duplicate, out-of-order và freshness theo phân vị.
• Xác minh reconnect không tạo snapshot sai hoặc data gap ẩn.
• Lưu config, raw update, log, dashboard query và kết quả máy đọc được.

Pass trên một model/path không chứng minh mọi native/OpenConfig path đúng. Một collector chịu được baseline không chứng minh chịu được alarm storm, burst hoặc schema churn. Timestamp đúng cú pháp cũng không chứng minh clock đúng; dashboard đẹp không chứng minh pipeline không mất mẫu.

gNMI specification định nghĩa hành vi giao diện, không đặt SLO vận hành hay retention. Kết luận phải giới hạn theo target/version, path, subscription, traffic profile, quy mô và điều kiện lỗi đã chạy.

• gNMI: giao diện quản lý mạng dựa trên gRPC.
• Subscribe: RPC nhận snapshot hoặc stream update.
• SAMPLE: phát giá trị theo chu kỳ.
• ON_CHANGE: phát khi giá trị thay đổi.
• Heartbeat: update định kỳ dù giá trị không đổi.
• Freshness: độ trễ từ thời điểm nguồn tới điểm tiêu thụ.
• Backpressure: cơ chế phản hồi khi downstream xử lý chậm.