Bài 4: gNMI và gRPC Streaming Telemetry – Mạng tự giám sát, cảnh báo tức thì, không cần SNMP

[dangquangminh]

Bài 4: gNMI và gRPC Streaming Telemetry – Mạng tự giám sát, cảnh báo tức thì, không cần SNMP

Hãy tưởng tượng hệ thống giám sát của bạn không còn phải “poll” dữ liệu kiểu 5 phút/lần, chậm chạp như SNMP. Thay vào đó, switch và router tự động “đẩy” dữ liệu về server giám sát ngay khi có thay đổi. Gần như real-time, không mất thời gian chờ, không tốn CPU thiết bị.

Đó chính là sức mạnh của gNMI và gRPC Telemetry – thế hệ mới trong giám sát và tự động hóa mạng.

---

📡 Vấn đề của giám sát truyền thống (SNMP)


Với SNMP, bạn chỉ có thể:

• Đọc dữ liệu theo chu kỳ → trễ thông tin
• Không kiểm soát được thời điểm thiết bị có vấn đề
• Dữ liệu thường ở định dạng khó phân tích (MIB, OID)
• SNMP Trap thì không tin cậy và khó mở rộng

Trong kỷ nguyên NetDevOps và Cloud-Native, những giới hạn này là không chấp nhận được.

---

🚀 Giải pháp: gNMI và gRPC Streaming Telemetry


gNMI (gRPC Network Management Interface) là giao thức mã nguồn mở được Google khởi xướng, hiện được nhiều hãng lớn như Cisco, Juniper, Arista hỗ trợ. Nó hoạt động dựa trên gRPC, cho phép truyền dữ liệu theo mô hình:

• Subscribe-Push: thiết bị đẩy dữ liệu về collector
• Secure: dùng TLS
• Structured: dựa trên mô hình dữ liệu YANG
• Efficient: nhẹ, tốc độ cao, hỗ trợ compress

---

🛠 Cách hoạt động của gNMI Streaming


Thay vì hỏi “interface này CPU bao nhiêu rồi?”, bạn chỉ cần đăng ký (subscribe) một luồng dữ liệu, ví dụ: interface.statistics, và thiết bị sẽ tự gửi thông tin này về collector mỗi khi có thay đổi hoặc theo khoảng thời gian định trước.

Có hai kiểu subscription phổ biến:

• Sample: gửi dữ liệu đều đặn theo thời gian (ví dụ: mỗi 10 giây)
• OnChange: chỉ gửi khi có thay đổi (ví dụ: khi interface down)

---

🧪 Cấu hình cơ bản Streaming Telemetry trên IOS XR


Cisco IOS XR hỗ trợ gNMI và gRPC qua CLI như sau:

telemetry model-driven destination-group 100 address-family ipv4 192.0.2.100 port 57500 encoding self-describing-gpb sensor-group 100 sensor-path interface-statistics subscription 100 sensor-group-id 100 sample-interval 10000 destination-id 100



Trong đó:

• sensor-path: là luồng dữ liệu cần thu thập (interface, CPU, BGP, v.v…)
• sample-interval: chu kỳ gửi dữ liệu (miligiây)
• destination: collector hoặc Prometheus/Grafana server

---

🔐 Xác thực và kết nối


gNMI yêu cầu TLS nên bạn cần cài đặt chứng chỉ server và client. Dữ liệu được gửi qua cổng mặc định 57400 (hoặc 57500 tùy nền tảng).

Collector có thể là:

• InfluxDB + Telegraf
• Prometheus
• OpenConfig gNMI client
• Custom script viết bằng Go/Python

---

🧠 Lợi ích thực tế của gNMI và Streaming Telemetry

• Giảm tải thiết bị: không cần phản hồi liên tục các truy vấn SNMP
• Nhanh chóng: phát hiện ngay khi có sự kiện mạng xảy ra
• Dữ liệu có cấu trúc: dễ parsing, dễ visualization (Grafana, Kibana)
• Tích hợp AI/ML dễ dàng: vì dữ liệu đều đặn, đầy đủ, chuẩn hóa

---

💡 So sánh thực tế


Giả sử một link uplink bị flapping 3 lần trong vòng 30 giây.

• SNMP: có thể bỏ lỡ hoàn toàn nếu thời gian poll là 60 giây
• gNMI: sẽ ghi lại đầy đủ 3 lần flapping, với dấu thời gian chính xác từng lần

---

🔧 Gợi ý thực hành


Muốn bắt đầu thử? Anh em có thể:

• Dùng Cisco Sandbox của DevNet
• Cài thử Telegraf + InfluxDB + Grafana để làm collector
• Dùng Python hoặc Go thử viết 1 client nhận dữ liệu từ router

---

🧭 Kết luận


gNMI và gRPC Streaming Telemetry không chỉ là công nghệ mới – nó là cách tiếp cận mới: thiết bị mạng chủ động nói chuyện với hệ thống giám sát, thay vì bị hỏi như xưa.

Điều này mở đường cho các kiến trúc NetDevOps tự phục hồi (self-healing), cảnh báo tức thì, và các hệ thống AI/SOC thông minh hơn.

---