Posted inNetworking

Giám sát mạng thời gian thực với Streaming Telemetry (gNMI), Telegraf và InfluxDB

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

Vấn đề thực tế: Điểm mù 5 phút của cơ chế SNMP Polling

Quý trước, đường trunk SIP chính của chúng tôi bắt đầu rớt cuộc gọi ngẫu nhiên tại ba văn phòng khu vực. Điểm chất lượng thoại (MOS) tụt dốc không phanh từ mức 4.3 mượt mà xuống chỉ còn 1.8. Cứ 20 phút nhân viên chi nhánh lại nghe thấy tiếng rè giật cục, thế nhưng dashboard giám sát của chúng tôi vẫn báo xanh an toàn. Tỷ lệ sử dụng interface trung bình chỉ quanh quẩn ở mức 42%, CPU switch core dừng ở mức 18% và bộ đếm lỗi trên interface hoàn toàn bằng không.

Trên giấy tờ, mọi thứ đều bình thường. Nhưng thực tế diễn ra trên đường truyền thì vô cùng tồi tệ.

Sau khi tap vào uplink bằng bộ tách quang (optical splitter) và tiến hành bắt gói tin bằng phần cứng, thủ phạm đã lộ diện ngay lập tức. Các tác vụ đồng bộ cơ sở dữ liệu nối tiếp nhau đang tạo ra các đợt bùng phát lưu lượng kéo dài 450 mili-giây ở tốc độ tối đa 100 Gbps line rate. Những đợt microburst này đã làm tràn bộ đệm gói tin dùng chung 32 MB của switch, âm thầm loại bỏ các gói voice RTP. Hệ thống giám sát mạng (NMS) của chúng tôi đã bỏ lỡ toàn bộ các đợt đột biến này chỉ vì nó quét thông số interface qua SNMP với chu kỳ 300 giây một lần.

SNMP đơn giản là đã tính trung bình hóa và làm lu mờ hiện thực. Một cổng 100G truyền tới hơn 140 triệu gói tin mỗi giây. Khi NMS chỉ lấy mẫu một lần sau mỗi 5 phút, nó sẽ san phẳng các đợt tăng vọt lưu lượng tức thời thành một đường cong mượt mà, vô hại. Các đợt microburst biến mất hoàn toàn trên biểu đồ, nhưng người dùng thì vẫn phải gánh chịu hậu quả gián đoạn dịch vụ.

Phân tích nguyên nhân gốc rễ: Vì sao kiến trúc Pull của SNMP thất bại trên mạng hiện đại

Các công cụ giám sát truyền thống không thể theo kịp tốc độ của các fabric mạng tốc độ cao. Kiến trúc nền tảng của SNMP áp đặt những giới hạn vật lý cứng nhắc mà không thể giải quyết đơn thuần bằng cách hạ thấp khoảng thời gian polling.

1. Sự kém hiệu quả của kiến trúc Pull-Based

SNMP phụ thuộc vào một collector trung tâm liên tục gửi các truy vấn UDP GetRequest lặp đi lặp lại qua hàng ngàn Object Identifier (OID). Hãy xem xét mức tải phát sinh trên một leaf switch top-of-rack 48 cổng tiêu chuẩn:

  • Collector gửi hàng trăm yêu cầu OID trong mỗi chu kỳ thăm dò chỉ để thu thập số lượng byte và gói tin cơ bản.
  • Bộ xử lý định tuyến (route processor) của switch phải ngắt control loop, thực hiện context-switch, duyệt qua cây Management Information Base (MIB) trong bộ nhớ, đóng gói phản hồi và gửi lại các gói tin UDP.
  • Trên các modular switch có hàng trăm interface vật lý và logic, các lệnh duyệt SNMP walk đẩy mức sử dụng CPU của control plane lên trên 40%. Trong những trường hợp nghiêm trọng, điều này khiến các giao thức định tuyến như BGP và OSPF bị bỏ đói tài nguyên CPU.

2. Bài toán Nyquist và hiện tượng Incast Burst

Các chỉ số thu thập qua polling chỉ cung cấp giá trị chênh lệch (delta) giữa hai mốc thời gian tùy ý, $T_1$ và $T_2$. Giả sử một interface hủy bỏ 14.000 gói tin trong một đợt burst kéo dài 200 ms tại giây thứ 12, sau đó hoàn toàn yên ắng trong 299 giây còn lại.

Một truy vấn SNMP được thực hiện ở giây thứ 300 sẽ phân bổ 14.000 gói bị hủy đó đều cho 300 giây, cho ra tỷ lệ rớt gói trung bình không đáng kể là 46 gói/giây. Bạn không thể nào phát hiện ra hiện tượng tail drop hay nghẽn TCP incast nếu không giảm chu kỳ polling xuống mức dưới một giây—tần suất sẽ ngay lập tức làm sập các tiến trình SNMP truyền thống.

3. Cấu trúc cây MIB phân mảnh và thiếu đồng nhất

Cấu trúc MIB của các nhà cung cấp nổi tiếng là hỗn tạp. Việc trích xuất công suất quang của transceiver (DOM), telemetry về độ sâu hàng đợi (queue-depth) hay trạng thái BGP peer trên một hạ tầng hỗn hợp chạy Cisco, Arista, Juniper và Linux SONiC đòi hỏi phải duy trì các bộ từ điển tra cứu OID tùy biến riêng biệt. Chỉ cần một bản nâng cấp hệ điều hành làm thay đổi một nhánh OID của doanh nghiệp, các dashboard sẽ hỏng ngay lập tức mà không có cảnh báo trước.

So sánh giải pháp: SNMP vs. Webhooks vs. Network Streaming Telemetry

Trước khi đại tu toàn bộ pipeline telemetry, chúng tôi đã đánh giá ba mô hình thu thập dữ liệu trong môi trường production:

Thuộc tính SNMPv2c / SNMPv3 HTTP Webhooks / Event Scripts gNMI / gRPC Streaming Telemetry
Cơ chế Pull (Polling định kỳ qua UDP) Push (HTTP POST phản ứng theo từng sự kiện) Push (Stream liên tục qua HTTP/2 trên nền gRPC)
Tần suất Thô (60s – 300s) Chỉ theo hướng sự kiện (khi đổi trạng thái) Dưới một giây (liên tục 1s hoặc khi có thay đổi)
Lược đồ dữ liệu SMIv2 MIB (OID) JSON không cấu trúc / Syslog YANG có cấu trúc (OpenConfig, IETF)
Tác động lên Control-Plane Cao (duyệt cây MIB bằng phần mềm) Trung bình (fork các script cục bộ) Không đáng kể (được offload sang cache nội bộ)
Bảo mật truyền tải Plaintext (v2c) hoặc USM cồng kềnh (v3) TLS (HTTPS) Mutual TLS (mTLS) native kèm xác thực token

Webhook hoạt động tốt đối với các cảnh báo tần suất thấp như đứt đường truyền. Nhưng chúng hoàn toàn sụp đổ trước hàng triệu bản cập nhật bộ đếm interface liên tục. Đối với các số liệu thời gian thực, gNMI (gRPC Network Management Interface) là tiêu chuẩn công nghiệp vượt trội không thể bàn cãi.

Kiến trúc hệ thống: gNMI, Telegraf và InfluxDB

Streaming telemetry đảo ngược hoàn toàn tư duy giám sát truyền thống. Thay vì một máy chủ bên ngoài liên tục hỏi xin số liệu bộ đếm, switch sẽ chủ động đẩy dữ liệu đi qua một kết nối HTTP/2 duy trì liên tục. Các bộ đếm được truyền trực tiếp từ cơ sở dữ liệu trạng thái nội bộ với độ phân giải lên tới micro-giây.

Pipeline production của chúng tôi sử dụng ba tầng cốt lõi:

  1. Các node mạng gNMI: Switch Cisco IOS-XE và Arista EOS xuất bản các data path OpenConfig YANG.
  2. Telegraf: Một daemon Go gọn nhẹ kết nối tới switch qua plugin inputs.gnmi để thu thập và phân tích các luồng protobuf.
  3. InfluxDB v2: Time-series database chuyên dụng lưu trữ số liệu với khả năng downsample và độ chính xác tới nanogiây.

Bước 1: Kích hoạt gNMI Server trên Switch

Hầu hết các hệ điều hành switch hiện đại đều tích hợp sẵn daemon gNMI. Dưới đây là cách mở dịch vụ gNMI trên các thiết bị enterprise tiêu chuẩn.

Trên Cisco IOS-XE (17.3+), kích hoạt gRPC server bảo mật cho các dial-in subscription từ bên ngoài kết nối vào:

! Kích hoạt cryptographic key và endpoint gRPC
netconf-yang
!
gnmi
  port 57400
  secure-port 57400
  secure-trustpoint Telemetry-mTLS
!

Trên Arista EOS (4.25+), kích hoạt provider Octa/gNMI trong context API quản trị:

management api gnmi
   transport grpc default
      port 57400
      ssl profile Telemetry-TLS-Profile
   provider eos-native
   no shutdown
!

Bước 2: Triển khai InfluxDB và Telegraf bằng Docker

Container hóa collector và cơ sở dữ liệu giúp việc triển khai trở nên đơn giản và có thể tái tạo dễ dàng. Dưới đây là file docker-compose.yml hoàn chỉnh:

version: '3.8'

services:
  influxdb:
    image: influxdb:2.7
    container_name: influxdb
    restart: unless-stopped
    ports:
      - "8086:8086"
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=netadmin
      - DOCKER_INFLUXDB_INIT_PASSWORD=ChangeThisPasswordNow123!
      - DOCKER_INFLUXDB_INIT_ORG=infrastructure
      - DOCKER_INFLUXDB_INIT_BUCKET=telemetry_raw
      - DOCKER_INFLUXDB_INIT_RETENTION=14d
      - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=SuperSecretTelegrafToken123!
    volumes:
      - influxdb_data:/var/lib/influxdb2

  telegraf:
    image: telegraf:1.30
    container_name: telegraf
    restart: unless-stopped
    depends_on:
      - influxdb
    network_mode: "host"
    volumes:
      - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
      - ./certs:/etc/telegraf/certs:ro

volumes:
  influxdb_data:

Bước 3: Cấu hình Dial-In gNMI Subscription trong Telegraf

Ở chế độ dial-in, Telegraf chủ động kết nối ra ngoài tới cổng 57400 của switch và yêu cầu các YANG data path cụ thể. Cách tiếp cận này giúp bạn không cần phải chạy các script tùy biến trực tiếp trên từng thiết bị mạng.

Thêm các block cấu hình target sau vào file telegraf.conf của bạn:

[agent]
  interval = "1s"
  round_interval = true
  metric_batch_size = 5000
  metric_buffer_limit = 50000
  collection_jitter = "0s"
  flush_interval = "1s"
  flush_jitter = "0s"
  logfile = ""

[[outputs.influxdb_v2]]
  urls = ["http://127.0.0.1:8086"]
  token = "SuperSecretTelegrafToken123!"
  organization = "infrastructure"
  bucket = "telemetry_raw"

# Input: Client gNMI dial-in kết nối tới các leaf switch
[[inputs.gnmi]]
  addresses = ["10.10.1.1:57400", "10.10.1.2:57400"]
  username = "telemetry_svc"
  password = "ServiceAccountPass123!"
  redial = "10s"
  encoding = "proto"

  # Điều chỉnh xác thực TLS tùy theo cấu hình PKI của bạn
  insecure_skip_verify = false
  tls_ca = "/etc/telegraf/certs/ca.pem"
  tls_cert = "/etc/telegraf/certs/telegraf.crt"
  tls_key = "/etc/telegraf/certs/telegraf.key"

  # Subscription 1: Lấy mẫu counter interface định kỳ mỗi 1 giây
  [[inputs.gnmi.subscription]]
    name = "interfaces"
    origin = "openconfig-interfaces"
    path = "/interfaces/interface/state/counters"
    subscription_mode = "sample"
    sample_interval = "1s"

  # Subscription 2: Bắt sự thay đổi trạng thái hoạt động của port theo hướng sự kiện
  [[inputs.gnmi.subscription]]
    name = "interface_oper_status"
    origin = "openconfig-interfaces"
    path = "/interfaces/interface/state/oper-status"
    subscription_mode = "on_change"

Bước 4: Khởi chạy và kiểm tra luồng dữ liệu

Khởi chạy telemetry collector stack chạy ngầm dưới nền:

docker compose up -d

Theo dõi log của collector để đảm bảo quá trình bắt tay TLS và đăng ký các đường dẫn YANG đã thành công:

docker logs -f telegraf

Bạn sẽ thấy các thông báo kết nối hoàn toàn thông suốt, không xuất hiện lỗi parse schema:

2026-10-14T12:00:01Z I! [inputs.gnmi] Đã kết nối [10.10.1.1:57400]
2026-10-14T12:00:01Z I! [inputs.gnmi] Đã kết nối [10.10.1.2:57400]
2026-10-14T12:00:02Z I! [inputs.gnmi] Đã khởi tạo subscription cho openconfig-interfaces:/interfaces/interface/state/counters

Bước 5: Truy vấn số liệu chi tiết trong InfluxDB

Mở giao diện InfluxDB UI tại http://<collector-ip>:8086. Để tính toán thông lượng gói tin và theo dõi các đợt microburst trên từng uplink 100G riêng biệt, hãy chạy truy vấn Flux sau:

from(bucket: "telemetry_raw")
  |> range(start: -15m)
  |> filter(fn: (r) => r["_measurement"] == "interfaces")
  |> filter(fn: (r) => r["_field"] == "in_octets" or r["_field"] == "in_discards")
  |> filter(fn: (r) => r["interface_name"] == "HundredGigE1/0/1")
  |> derivative(unit: 1s, nonNegative: true)
  |> yield(name: "real_time_rate")

Với khoảng thời gian lấy mẫu 1 giây, sự khác biệt thể hiện rõ rệt ngay tức thì. Đợt replication burst 450 ms từng ẩn mình sau đường thẳng trung bình 42% giờ đây hiển thị rõ ràng thành một đỉnh nhọn 98 Gbps, bám sát ngay sau đó là 2.300 gói tin bị hủy ở chiều vào (input discards). Thời gian xác định nguyên nhân gốc rễ giảm từ 4 giờ tranh cãi xuống chỉ còn 10 giây quan sát biểu đồ trực quan.

Kinh nghiệm thực chiến và khuyến nghị thực tế

Chuyển từ cơ chế pull polling sang push telemetry đã giúp giảm mức sử dụng CPU trên switch của chúng tôi từ 28% xuống chỉ còn 2.4%. Nó cũng giúp phát hiện ba lỗi rớt gói âm thầm trên các spine switch chỉ trong vòng hai tuần. Để giữ cho pipeline hoạt động ổn định khi mở rộng quy mô, hãy tuân thủ các nguyên tắc thực tế sau:

  • Sử dụng subscription on_change cho các cờ trạng thái: Đừng bao giờ poll trạng thái định tuyến hay trạng thái hoạt động của liên kết (link operational status) theo chu kỳ 1 giây. Đăng ký ở chế độ on_change sẽ loại bỏ các mẫu dữ liệu rỗng không đổi. Bạn sẽ nhận được thông báo chỉ trong vài mili-giây khi một BGP session bị ngắt kết nối, vừa tiết kiệm dung lượng lưu trữ cơ sở dữ liệu vừa giảm băng thông mạng.
  • Phân tầng tần suất lấy mẫu hợp lý: Số lượng gói tin interface và lượng gói bị drop trong bộ đệm có độ ưu tiên cao hoàn toàn xứng đáng với chu kỳ cập nhật 1 giây. Các cảm biến môi trường, nhiệt độ khung máy và module quang học (DOM) chỉ biến thiên qua từng phút; hãy stream các dữ liệu này mỗi 30 hoặc 60 giây một lần.
  • Thắt chặt bảo mật cho cổng quản trị switch: Bảo vệ cổng TCP 57400 bằng tính năng Control-Plane Policing (CoPP) phần cứng và Access Control List (ACL). Giới hạn kết nối telemetry nghiêm ngặt chỉ từ các địa chỉ IP của collector, đồng thời cách ly các tài khoản người dùng telemetry chỉ với quyền đọc (read-only).

SNMP đã hoàn thành tốt vai trò lịch sử của mình trong suốt ba thập kỷ qua. Nhưng hạ tầng mạng đám mây hiện đại cần những công cụ hiện đại tương xứng. Việc kết hợp gNMI, Telegraf và InfluxDB đem lại cho bạn khả năng giám sát tức thì, chi tiết dưới một giây trên mọi cổng mạng mà không hề làm quá tải control plane của thiết bị.

Share:
Tags: