网络笔记：Syslog、SNMP 与 Telemetry——设备数据怎么出来

上一篇讲的是「人怎么排错」。这一篇讲「机器怎么把数据交出来」——这是自动化运维的地基。

三种采集方式，定位完全不同

Syslog、SNMP 与 Telemetry 三种数据采集方式的对比 — ▲ 一个推、一个拉、一个事件驱动，实际环境里三个一起用

	Syslog	SNMP	Telemetry
方向	设备 → 服务器（推）	网管 → 设备（拉）	设备 → 采集器（推）
内容	事件日志（文本）	指标（结构化 OID）	任意数据（可自定义订阅）
触发	有事件才发	定时轮询，通常分钟级	周期推送，可到秒级 / 亚秒级
协议	UDP 514	UDP 161，Trap 用 162	gRPC / UDP / HTTP
主要用途	故障回溯、合规审计	趋势监控、阈值告警	实时监控、大数据分析、闭环调优
痛点	只有事件，没有连续指标	轮询间隔一短，设备 CPU 就顶不住	需要采集器支持，对网络质量敏感

一句话记住三者的差别：Syslog 是「出事了告诉你」，SNMP 是「我每隔几分钟来问你一句」，Telemetry 是「我按你订的节奏不停报数」。前两个是「事后知道」，Telemetry 才谈得上「实时」。

Syslog：日志怎么规范地发出去

Syslog 的报文由三部分组成：PRI（优先级）+ HEADER（时间戳、主机名）+ MSG（内容）。PRI 里的 severity 一共 8 级，从 0 到 7，数字越小越严重：

级别	名称	含义
0	Emergency	系统不可用
1	Alert	必须立刻处理
2	Critical	严重故障
3	Error	错误
4	Warning	警告
5	Notification	正常但重要
6	Informational	一般信息
7	Debugging	调试信息

设备侧配置：

huawei · syslog

# ① 开启信息中心（默认已开）
info-center enable

# ② 指定日志服务器
info-center loghost 10.1.1.100

# ③ 指定源接口（服务器上按源 IP 区分设备，建议配环回口）
info-center loghost source LoopBack0

# ④ 按模块和级别过滤：只发 warning(4) 及以上
info-center source default channel 2 log level warning

# ⑤ 时间戳格式（便于日志平台解析）
info-center timestamp loghost date

# ★ 排错要点：
#   UDP 514 是单向的，丢包不会重传 —— 关键日志别只依赖 Syslog
#   别忘了配 source，否则服务器上看到的源地址是出接口地址，
#   设备重启或链路切换后源地址变化，日志就串了

SNMP：拉模式的老将

SNMP 的核心是 MIB + OID：设备把可被查询的状态组织成一棵树，每个叶子节点有一个 OID 编号，网管按 OID 去取。

版本	认证方式	说明
v1	团体字（明文）	最老，只有 get / set / trap
v2c	团体字（明文）	加了 getbulk，批量取效率高，目前最常用
v3	用户 + 认证 + 加密	支持 MD5/SHA 认证和 DES/AES 加密，安全性最高

huawei · snmp v2c / v3

# v2c：团体字只读
snmp-agent
snmp-agent sys-info version v2c
snmp-agent community read cipher Huawei@123
snmp-agent target-host trap address udp-domain 10.1.1.100 params securityname Huawei@123 v2c
snmp-agent trap enable

# v3：认证 + 加密（生产环境推荐）
snmp-agent sys-info version v3
snmp-agent usm-user v3 monitor group read-group authentication-mode sha2-256
snmp-agent usm-user v3 monitor authentication-mode sha2-256 cipher Auth@123
snmp-agent usm-user v3 monitor privacy-mode aes128 cipher Priv@123

# 被管信息包含哪些视图
snmp-agent mib-view included iso-view iso

SNMP 的两个坑

坑

坑一：轮询间隔太短把设备 CPU 打满
  网管默认 5 分钟轮一次，一旦改成 10 秒，上百台设备同时被拉，
  设备 SNMP 进程会占满 CPU，严重时业务转发都受影响。
  ★ 高频需求不要用 SNMP 硬拉，换 Telemetry。

坑二：Trap 是 UDP，丢了就丢了
  接口 down 的 Trap 恰好丢了，你就完全不知道。
  ★ 关键事件要做双保险：Trap 告警 + Syslog 留档 + 主动巡检兜底。

NetStream / NetFlow：换个维度看流量

前面三个看的都是「设备本身的状态」。要看「谁在跟谁通信、占了多少带宽」，得用流级别的统计。华为叫 NetStream，思科叫 NetFlow，标准叫 IPFIX，思路一样：

	端口镜像	NetStream / NetFlow
给什么	完整原始报文	流统计信息（五元组 + 字节数 + 包数）
适合	抓包定位协议交互问题	带宽分析、异常流量发现、计费
开销	大，镜像口带宽要够	中，设备要维护流表
能否看内容	能，能看到报文内部	不能，只有统计

huawei · netstream

# 全局开启
netstream export source interface LoopBack0
netstream export host 10.1.1.200 9995

# 接口上开启统计
interface GigabitEthernet0/0/1
 ip netstream inbound
 ip netstream outbound

# 采样（高负载链路建议采样，降低设备压力）
interface GigabitEthernet0/0/1
 ip netstream sampler fix-packets 1000 inbound   # 每 1000 个包采 1 个

# 看流缓存
display ip netstream cache

Telemetry：从「拉」到「推」的范式转变

Telemetry 的思路是设备主动、周期性地把数据推给采集器，不再等网管来问。好处很直接：

	SNMP 轮询	Telemetry 推送
方向	网管拉，设备被动响应	设备推，一次订阅长期生效
采集精度	分钟级	秒级，最快可到亚秒级
设备开销	每轮都要遍历 OID 树，开销随频率线性上升	一次订阅后按增量上报，开销可控
数据格式	扁平的 OID → 值	结构化（GPB / JSON），带层级关系
适用场景	常规趋势监控	实时流量分析、丢包微突发、AI 运维训练数据

订阅分两种：静态订阅（采集器不在线，设备也照发，配置在设备上）和动态订阅（采集器上线后下发订阅，设备才发）。生产上动态订阅更常用。

huawei · telemetry 静态订阅（gRPC）

# ① 配置采集目标
telemetry
 #
 destination-group D1
  ipv4-address 10.1.1.200 port 57000 protocol grpc no-tls
 #
 # ② 订阅哪些数据
 sensor-group S1
  sensor-path huawei-ifm:ifm/interfaces/interface
  sensor-path huawei-devm:devm/cpuInfos/cpuInfo
 #
 # ③ 多久采一次
 subscription-group SUB1
  local-source-address 10.1.1.1
  sensor-group S1 sample-interval 5000      # 单位毫秒 → 5 秒
  destination-group D1
  commit

# ★ 关键参数
#   sample-interval：采样间隔（毫秒）。设太小会给设备和网络带来压力
#   protocol：grpc（推荐，高效）/ udp / http
#   no-tls / tls：加密开关

为什么现在都往 Telemetry 走？因为「拉」这个动作本身就是瓶颈——网管要维护每台设备的轮询队列，设备要为每个请求遍历一遍 MIB 树。设备数量一多、频率一高，两边都崩。推送模型把「谁来发起」这件事反转了，开销从「次数 × 设备数」变成了「一次订阅 + 固定周期」。

NETCONF / YANG：管「写」的那一半

上面讲的都是「读数据」。真正做自动化，还需要一个标准的「写配置」接口——这就是 NETCONF + YANG。

组件	作用
NETCONF	协议本身，跑在 SSH 上（默认 830 端口），用 XML 交互
YANG	数据模型语言，定义「设备有哪些配置项、什么类型、什么层级」
NETCONF 操作	`get` / `get-config` / `edit-config` / `commit` / `lock` / `copy-config`
Candidate 库	改配置先写候选库，确认无误再 `commit`——天然带事务和回滚

huawei · netconf

# 设备侧开启 NETCONF
netconf
netconf enable

# 检查状态
display netconf status

# 控制器侧（Python ncclient 示意）
# from ncclient import manager
# with manager.connect(host="10.1.1.1", port=830, username="admin",
#                      password="***", hostkey_verify=False) as m:
#     m.edit_config(target="candidate", config=yang_xml)
#     m.commit()          # ★ 确认无误才提交，出错可 discard-changes 回滚

为什么要用 NETCONF，而不是继续用 SSH 敲命令

	SSH + CLI 脚本	NETCONF + YANG
输出格式	文本，靠正则抓，设备升级就可能变	结构化 XML，字段稳定
幂等性	要自己判断「这条配过了没有」	模型驱动，天然幂等
事务	没有，配一半出错就停在中间	有 candidate + commit，可回滚
并发	多人同时改会互相覆盖	有 lock，能互斥

自动化运维的标准组合，就是把这几件拼起来：

自动化运维的完整组合

写配置   →  NETCONF / YANG（标准、事务、幂等）
读状态   →  Telemetry（高频、结构化）
事件日志 →  Syslog（留档、审计）
趋势指标 →  SNMP（兼容老设备）
流量视角 →  NetStream / NetFlow
编排调度 →  控制器 / 网管平台（iMaster NCE 等）

★ 四层分工：配置面（NETCONF）+ 监控面（Telemetry/SNMP）
  + 日志面（Syslog）+ 分析面（NetStream + 采集器）

怎么选：一张决策表

需求	用什么
要实时看到接口流量、丢包微突发	Telemetry（秒级推送）
要常规趋势图、阈值告警	SNMP（分钟级足够）
要排查「谁占了带宽」	NetStream / NetFlow
要定位协议交互问题	端口镜像 + Wireshark
要合规审计、故障回溯	Syslog 集中收集
要批量下发配置、做自动化	NETCONF / YANG + 控制器

一句话总结：Syslog 管「出了什么事」，SNMP 管「现在什么样」，Telemetry 管「此刻正在怎么变」，NetStream 管「谁在用带宽」，NETCONF 管「怎么把配置写下去」。五件事各司其职，别指望一个协议全包。

📌 本篇整理自 2024–2025 的「数通」学习笔记（HCIE-Datacom 方向）

合并了原始笔记中「syslog / telemetry / netconf / 自动化」四页，并把「网络管理」里的采集手段一节展开成对比表。
原笔记以截图 + OCR 文本为主（识别错误较多），本文按「三种采集方式 → 日志 / 轮询 / 推送 → 写配置接口 → 决策表」重写。
配置命令保留华为 VRP 原样；Telemetry 的 sample-interval 与 NETCONF 的 candidate 库是原笔记里容易漏掉的关键点。