第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 采样发现短时拥塞 |
思考
- Telemetry 相比 SNMP 的核心优势是什么?
- Dial-out 和 Dial-in 模式有什么区别?为什么推荐 Dial-out?
- 华为设备 Telemetry 的配置分为哪三个步骤?
- 什么是传感器路径(Sensor Path)?常用的有哪些?
- 如何用 Telemetry 检测微突发(Microburst)?
- Telegraf 在 Telemetry 采集链中扮演什么角色?
下篇预告:第285篇 - Telemetry 数据采集与模型驱动,深入 Telemetry 的数据模型和基于 YANG 驱动的采集框架。