第284篇:数据中心网络监控:Telemetry 与 gRPC

关键词

Telemetry、gRPC、流式数据采集、gRPC Dial-in/Dial-out、Protobuf、模型驱动监控、SNMP 替代、华为 Telemetry


一、从 SNMP 到 Telemetry

1.1 SNMP 的局限

传统 SNMP 监控模式(PULL 模式):

监控系统 交换机 ┌──────┐ ┌──────┐ NMS ── SNMP GET ────► ◄────── Response ─ ── SNMP GET ────► ◄────── Response ─ ... Agent

SNMP 的痛点: ┌─ 轮询模式(PULL):NMS 主动问 ├─ 采集粒度粗:典型轮询间隔 5-15 分钟 ├─ 数据量小:每次 GET 只取几个 OID ├─ 网络开销大:大量 GET/Response 报文 ├─ 难以捕捉瞬间事件:亚秒级抖动无法发现 └─ 二进制 OID 解析繁琐:MIB 依赖

典型问题: 5 分钟轮询间隔 → 错过 90% 的微突发 1000 台设备 → 频繁读写 CPU 升高

1.2 Telemetry 优势

Telemetry 模式(PUSH 模式):

交换机 采集系统 ┌──────┐ ┌──────┐ gRPC Agent ── PUSH Data ────► ── PUSH Data ────► ── PUSH Data ────► 流式持续推送 gRPC Collect

Telemetry 的关键优势: ┌─ PUSH 模式:设备主动上报 ├─ 高频率:亚秒级(100ms/1s/10s) ├─ 高密度:一次上报数千条数据 ├─ 低延迟:实时推送,无轮询间隔 ├─ 结构化数据:YANG 模型 + Protobuf/JSON └─ 低 CPU 开销:设备按预定周期推送

1.3 监控能力对比

维度 SNMP Telemetry
采集模式 PULL(拉) PUSH(推)
采集频率 5-15 分钟 100ms-10s(可配置)
数据模型 MIB(私有) YANG(标准/厂商扩展)
编码格式 BER/TLV(二进制) Protobuf/JSON/GPB
传输协议 UDP(161) gRPC over HTTP/2
单设备数据量 低(几百条/轮询) 高(万级/秒)
CPU 开销 中(频繁 Parse) 低(按计划推送)
微突发检测 几乎不可能 秒级/亚秒级发现

二、gRPC Telemetry 协议

2.1 gRPC 基础

gRPC = Google Remote Procedure Call 基于 HTTP/2 + Protobuf 的高性能 RPC 框架

HTTP/2 多路复用 ┌───── Request ────┐ └──────────────────┘ 优势: ┌─ 单 TCP 连接支持多流 ├─ 头部压缩(HPACK) ├─ 服务器推送(Server Push) └─ 流式传输(Streaming) Stream 1: Data Stream 2: Data Stream 3: Data

2.2 Dial-in 和 Dial-out 模式

Telemetry 两种传输模式:

  ┌─ Dial-out 模式(推荐,最常用)
  │
  │  设备主动连接采集器
  │
  │  ┌──────────┐  建立 gRPC 连接   ┌────────┐
  │  │  交换机   │ ────────────────► │ 采集器 │
  │  │(gRPC     │   PUSH 数据       │(gRPC   │
  │  │ Server)  │ ────────────────► │ Client)│
  │  └──────────┘                    └────────┘
  │
  │  优势:
  │  ┌─ 设备主动出站,无需入站端口暴露
  │  ├─ 采集器宕机不影响设备(重新连接)
  │  └─ 适合大规模部署(设备端控制推送)

  ┌─ Dial-in 模式
  │
  │  采集器主动连接设备
  │
  │  ┌──────────┐  建立 gRPC 连接   ┌────────┐
  │  │  采集器   │ ────────────────► │ 交换机 │
  │  │(gRPC     │   Subscribe 请求  │(gRPC   │
  │  │ Client)  │  ◄──PUSH 数据──── │ Server)│
  │  └──────────┘                    └────────┘
  │
  │  适用:
  │  └─ 按需订阅,临时采集

2.3 华为 Telemetry 配置

华为 CloudEngine Telemetry 配置(Dial-out):

#
# 1. 定义传感器组(采集哪些数据)
#
telemetry
 sensor-group cpu-memory
  sensor-path huawei-device:/hw-device/
   cpu-usage
   memory-usage
  #
 sensor-group interface-statistics
  sensor-path huawei-ifm:/ifm/interfaces/
   interface/statistics
  #
 sensor-group bgp-stats
  sensor-path huawei-bgp:/bgp/
   peers/peer/statistics

#
# 2. 定义采集器目标
#
destination-group collector-group
  ip-address 192.168.100.100 port 10001
   protocol grpc no-tls
  ip-address 192.168.100.101 port 10001
   protocol grpc no-tls

#
# 3. 订阅(关联传感器和采集器)
#
subscription basic-sub
  sensor-group cpu-memory sample-interval 10
  sensor-group interface-stats sample-interval 30
  sensor-group bgp-stats sample-interval 60
  destination-group collector-group

三、Telemetry 数据模型

3.1 数据结构

Telemetry 数据封装结构(GPB 编码):

Telemetry Header ┌─ Node ID (设备ID) ├─ Node ID Value (设备名) ├─ Subscription ID (订阅ID) ├─ Sensor Path (路径) ├─ Collection Start Time (采集开始) └─ Collection End Time (采集结束) Telemetry Data (GPB/JSON) ┌─ 多个数据行 (Row) ├─ Timestamp (时间戳) ├─ Content (路径对应数据) └─ ...

YANG 模型示例(huawei-ifm): module: huawei-ifm +--rw ifm +--rw interfaces +--rw interface* [name] +--rw name string +--rw statistics +--ro in-bits uint64 +--ro out-bits uint64 +--ro in-discards uint32 +--ro out-discards uint32 +--ro in-errors uint32 +--ro out-errors uint32

3.2 常用传感器路径

华为设备常用 Sensor Path:

  接口统计:
    huawei-ifm:/ifm/interfaces/interface/statistics
    数据:入/出字节、包、丢弃、错误、广播/组播

  CPU/内存:
    huawei-device:/hw-device/cpu-usage
    huawei-device:/hw-device/memory-usage
    数据:CPU 利用率、内存利用率

  路由表:
    huawei-route:/route/routeTables/routeTable
    huawei-rib:/rib/ribTables/ribTable
    数据:路由条目数、路由变化

  BGP 状态:
    huawei-bgp:/bgp/peers/peer/statistics
    数据:BGP 邻居状态、前缀数、Update 消息

  VXLAN EVPN:
    huawei-evpn:/evpn/instances/instance
    数据:EVPN 实例、VNI、隧道、MAC 表

  QoS/队列:
    huawei-qos:/qos/queue-statistics
    数据:队列深度、丢弃、延迟

  流表(FIB):
    huawei-fib:/fib/entries/entry
    数据:FIB 条目、命中统计

四、采集器与数据流水线

4.1 数据采集架构

端到端 Telemetry 数据流水线:

交换机 1 └──────────┘ ───┐ ┌─────────┐ gRPC/PUSH ┌──────────┐ 时序数据库
┌──────────┐ ├──────────────► 交换机 2 └──────────┘ 采集器 ───┤ ─┤ InfluxDB gRPC Collector
--- --- ---
交换机 N └──────────┘ ───┘ 数据管道
--- ---
┌──────────────┐
│ 流处理/分析 │
│ Kafka/Flink │
└──────┬───────┘
▼ ▼ ▼
--- --- ---
┌──────────┐ ┌──────────┐ ┌──────────┐
可视化 Grafana 告警 Alert Manager

4.2 开源采集器

常用 Telemetry 采集工具:

1. Telegraf(推荐)
   ┌─ 插件丰富,支持 gRPC Telemetry
   ├─ 接收 → 解析 → 转发 → 时序 DB
   ├─ 配置简单
   └─ 社区活跃

   Telegraf 配置(/etc/telegraf/telegraf.conf):
   [[inputs.cisco_telemetry_mdt]]
     # Telemetry 监听地址
     service_address = ":10001"
     # 数据格式
     transport = "grpc"

   [[outputs.influxdb]]
     urls = ["http://localhost:8086"]
     database = "telemetry"

2. Pipeline(华为)
   ┌─ 华为配套采集器
   ├─ 支持 GPB/JSON 解析
   ├─ 对接 NCE Insight
   └─ 商用支持

3. 自定义采集器(Python)
   ┌─ 使用 gRPC 库直接接收
   ├─ 灵活处理数据
   └─ 适用于特殊场景

五、实用配置案例

5.1 接口流量监控(100ms 精度)

# 华为设备配置
telemetry
  sensor-group interface-high-freq
    sensor-path huawei-ifm:/ifm/interfaces/interface/statistics
      sample-interval 100    # 100ms 采集一次

  destination-group col-group
    ip-address 10.1.1.100 port 10001
      protocol grpc no-tls

  subscription high-freq-sub
    sensor-group interface-high-freq
    destination-group col-group

# Telegraf 接收
[[inputs.cisco_telemetry_mdt]]
  service_address = ":10001"
  transport = "grpc"

[[outputs.influxdb]]
  urls = ["http://localhost:8086"]
  database = "dc_telemetry"
  retention_policy = "30d"

# Grafana 查询
  SELECT last("in-bits") / 1000000 AS "In Mbps"
  FROM "interface_statistics"
  WHERE "interface_name" = '40GE1/0/1'
  AND $timeFilter
  GROUP BY time(1s)

5.2 微突发检测

Telemetry 发现微突发(Microburst):

└──────────────────────────────────────┘ 传统 SNMP(5 分钟平均):利用率 40% ✅ Telemetry(100ms 采样):峰值 95% ⚠️ → 发现微突发,调整队列或带宽 端口利用率 ███████████ ████████████████ 10ms 采样 时间 ▄▄▄▄ █ █

Grafana 告警规则: ┌─ 当 in-bits(100ms 平均)> 90% 端口带宽 ├─ 持续时间 > 1 秒 └─ 触发告警:接口流突


六、Telemetry 最佳实践

生产环境 Telemetry 建议:

1. 采样频率设计
   ┌─ 接口统计:100ms-1s(检测微突发)
   ├─ CPU/内存:5-10s
   ├─ BGP 状态:10-30s
   └─ 路由表/FIB:30-60s

2. 采集器架构
   ┌─ 多采集器(HA 部署,2-3 台)
   ├─ 每台采集器支撑 500-1000 设备
   ├─ 使用 Kafka 缓冲(应对采集器重启)
   └─ 数据保留策略:原始数据 7d,聚合 30d

3. 安全加固
   ┌─ 生产环境使用 TLS 加密(protocol grpc tls)
   ├─ 证书管理(设备证书 + CA 证书)
   ├─ 采集器访问控制
   └─ 管理网络与业务网络分离

4. 数据治理
   ┌─ 定义数据标签规则(设备名/角色/机房)
   ├─ 标准化字段命名
   ├─ 数据质量监控(丢失率/延迟)
   └─ 定期审计数据完整性

总结

关键点 说明
Telemetry 本质 PUSH 模式替代 SNMP 的 PULL
核心优势 亚秒级精度、大规模并发、低 CPU
传输协议 gRPC over HTTP/2(Dial-out 为主)
数据模型 YANG 模型 + GPB/Protobuf 编码
华为配置 sensor-group → destination-group → subscription
采集链 Telegraf → Kafka/InfluxDB → Grafana
微突发检测 100ms 采样发现短时拥塞

思考

  1. Telemetry 相比 SNMP 的核心优势是什么?
  2. Dial-out 和 Dial-in 模式有什么区别?为什么推荐 Dial-out?
  3. 华为设备 Telemetry 的配置分为哪三个步骤?
  4. 什么是传感器路径(Sensor Path)?常用的有哪些?
  5. 如何用 Telemetry 检测微突发(Microburst)?
  6. Telegraf 在 Telemetry 采集链中扮演什么角色?

下篇预告:第285篇 - Telemetry 数据采集与模型驱动,深入 Telemetry 的数据模型和基于 YANG 驱动的采集框架。