当网络“静悄悄地坏掉”
你的监控系统在哪里？

Chapter One · 监控的第一性原理

为什么监控会有“盲区”？

在我们打开任何一份 OID 表格之前，请先停下来想一个问题——
如果监控系统从未告警，是不是就意味着网络一切正常？
过去十五年的运维经验告诉我：恰恰相反。最危险的故障，往往就藏在“监控保持沉默”的缝隙里。

监控盲区图谱：你看见的，远不是网络的全部

下图把网络故障按“可观测性”做了分层。越往下，故障越隐蔽，但对业务 SLA 的影响越深远。

图 1-1 · 网络故障的三层可观测性。盲区不是“没监控”，而是“监控的维度选错了”。

本白皮书的设计哲学：分层 · 多维 · 变化

图 1-2 · 网络监控分层模型。本白皮书后续章节将逐层落到具体 OID。

监控的终点，不是看到红灯亮起，
而是在红灯亮起之前，听见网络的咳嗽声。

→ 下一章，我们将把“分层 · 多维 · 变化”三原则，
落到第一个真实战场：端口 Downshift 与线缆质量监控。

Chapter Two · 物理层的真相

当端口"Up"成为最大的谎言

想象一个画面：Catalyst 9300LM 的 mGig 端口连着一台 9120 AP， ifOperStatus = up(1)，绿灯稳定。运维大屏一片祥和。
可就在此刻，AP 上的用户正在不断重连，IP 电话在嘶嘶杂音，视频会议卡成 PPT——
这就是 Downshift（速率自动降级）悄悄发生的样子。

2.1 一次真实事件的时序还原

下面的 SVG 还原了客户现场那段 Downshift 抖动的完整过程：

图 2-1 · Downshift 事件的三个阶段。如果只看 Up/Down，整个故障期都是"绿灯"。

2.2 第一性原理：什么才是物理层真正的"生命体征"？

从第一性原理出发，物理层只有 3 个核心问题需要回答：

1. 链路在以什么速率运行？（速率维度）
2. 线缆/光纤的物理质量如何？（介质维度）
3. 有多少帧因物理层错误被丢弃？（错误率维度）

Downshift 不是一个"事件"，而是物理层在向你大喊：
"我撑不住了！"

2.3 核心 OID 体系（一）：速率与链路状态

下表所有 OID 已与上传的 IF-MIB.my、CISCO-IF-EXTENSION-MIB.my 源码逐一核对。

2.4 核心 OID 体系（二）：Cisco 私有扩展（震荡与状态变化原因）

标准 IF-MIB 只能告诉你"端口 Down 了"，告诉不了你"为什么 Down"。 Cisco 在 CISCO-IF-EXTENSION-MIB 中给出了答案：

2.5 核心 OID 体系（三）：TDR 线缆诊断（CISCO-CABLE-DIAG-MIB）

TDR（Time Domain Reflectometry，时域反射）是物理层诊断的"X 光机"—— 它向线缆发送脉冲信号，根据反射波分析故障点距离、线对极性、阻抗匹配。 这是排查"端口 Up 但 SNR 烂掉"的唯一非破坏性手段。

2.6 核心 OID 体系（四）：Auto-Negotiation 协商真相（MAU-MIB）

想直接观测"协商出来的 Downshift"？MAU-MIB 提供了链路两端的协商能力快照。

2.7 Zabbix 实战配置：Downshift 检测全流程

Step 1 · 用 LLD 自动发现物理端口

{
  "name": "Cisco mGig Physical Ports Discovery",
  "type": "SNMP_AGENT",
  "snmp_oid": "discovery[{#IFINDEX},1.3.6.1.2.1.31.1.1.1.1, {#IFNAME},1.3.6.1.2.1.31.1.1.1.1, {#IFALIAS},1.3.6.1.2.1.31.1.1.1.18, {#IFTYPE},1.3.6.1.2.1.2.2.1.3, {#CONNECTOR},1.3.6.1.2.1.31.1.1.1.17]",
  "filter": {
    "evaltype": "AND",
    "conditions": [
      { "macro": "{#CONNECTOR}", "value": "1", "operator": "MATCHES_REGEX" },
      { "macro": "{#IFTYPE}",    "value": "^6$|^117$", "operator": "MATCHES_REGEX" }
    ]
  },
  "lifetime": "30d"
}

说明：过滤条件保留 ifConnectorPresent=true(1) 且 ifType 为 ethernetCsmacd(6) 或 gigabitEthernet(117) 的接口， 自动剔除 Loopback、SVI、Tunnel 等逻辑接口。

Step 2 · 关键 Item 模板（按 LLD 原型）

# 1. 当前协商速率（Mbps）— Downshift 主指标
Item Key:        net.if.speed.high[{#IFINDEX}]
SNMP OID:        1.3.6.1.2.1.31.1.1.1.15.{#IFINDEX}
Type:            Numeric (unsigned)
Update interval: 30s
Preprocessing:   Discard unchanged with heartbeat: 600s
Tags:            tier:L1, scenario:downshift

# 2. Carrier Transition 次数（震荡核心证据）
Item Key:        cisco.if.carrier.trans[{#IFINDEX}]
SNMP OID:        1.3.6.1.4.1.9.9.276.1.1.2.1.4.{#IFINDEX}
Type:            Numeric (unsigned, Counter32 → delta)
Update interval: 60s
Preprocessing:   Change per second
Tags:            tier:L1, scenario:flapping

# 3. State Change Reason（人类可读原因）
Item Key:        cisco.if.state.reason[{#IFINDEX}]
SNMP OID:        1.3.6.1.4.1.9.9.276.1.1.2.1.3.{#IFINDEX}
Type:            Character
Update interval: 60s

# 4. ifOperStatus
Item Key:        net.if.status[{#IFINDEX}]
SNMP OID:        1.3.6.1.2.1.2.2.1.8.{#IFINDEX}
Update interval: 30s

# 5. 入向错误帧增长率
Item Key:        net.if.in.errors[{#IFINDEX}]
SNMP OID:        1.3.6.1.2.1.2.2.1.14.{#IFINDEX}
Type:            Counter32
Update interval: 60s
Preprocessing:   Change per second

Step 3 · 触发器矩阵（含告警分级）

Step 4 · SNMP Trap 双通道（事件驱动）

除了 Polling，强烈建议在 Cisco IOS 上启用 Trap 主动通告：

! 在 Catalyst 9300LM 上配置：
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps cef-mac-move
snmp-server enable traps interface
snmp-server host 10.x.x.x version 2c <community> udp-port 162  snmp interface

! Zabbix Trap 接收侧（snmptrapd + Trapper Item）：
Trap OID: 1.3.6.1.6.3.1.1.5.3   (linkDown)
Trap OID: 1.3.6.1.6.3.1.1.5.4   (linkUp)
Trap OID: 1.3.6.1.4.1.9.9.276.0.1  (cieLinkDown - 携带额外 ifName/ifType)

2.8 一图总览：物理层告警优先级矩阵

图 2-2 · 物理层 6 个监控维度的优先级、采样频率与关键 OID 速查表。

监控物理层，不要等"灯灭"，要听"咳嗽"——
ifHighSpeed 的每一次跌落，都是网络在告诉你它需要看医生。

→ 下一章，我们将进入更深的水域：
Cisco SDA 全栈监控（Underlay · Overlay · Control Plane）， 看 IS-IS、LISP、VXLAN 这些"看不见的协议"如何被精准捕获。

Chapter Three · 看不见的网络

当 SDA 的"地基"开始下沉

传统网络是"水平的"——一根光纤从 A 到 B，看得见摸得着。
Cisco SDA 是"立体的"—— 下面跑 IS-IS 织出 Underlay 路由地基，
中间用 VXLAN 隧道封装承载， 上面用 LISP 的 Map-Server 像 DNS 一样查询终端位置。
三层任何一层出问题，业务都会瘫痪——而你可能完全不知道。

3.1 先看清地图：SDA 的三层立体结构

图 3-1 · SDA 三层架构与监控分工。Underlay 是地基，Control Plane 是大脑，Overlay 是血管。

3.2 Underlay 监控（一）：IS-IS 邻居与 LSP 数据库

Cisco SDA 在 Underlay 默认使用 IS-IS（而非 OSPF），原因是 IS-IS 与 IP 解耦， 天然支持 IPv6/IPv4 双栈、收敛快、对大规模 fabric 友好。 所有 OID 来自您上传的 CISCO-IETF-ISIS-MIB。

关键 IS-IS Trap（事件驱动核心）

3.3 Underlay 监控（二）：BFD 毫秒级故障检测

BFD（Bidirectional Forwarding Detection）是 SDA Underlay 的"心电监护仪"—— 它独立于路由协议，以毫秒级周期发送 hello 包， 故障检测时间可压缩到 50ms 以内，远快于 IS-IS 的默认 30 秒 Hold Time。

BFD 关键 Trap

• ciscoBfdSessUp · 1.3.6.1.4.1.9.10.137.0.1 · 会话恢复
• ciscoBfdSessDown · 1.3.6.1.4.1.9.10.137.0.2 · ★会话失联（核心告警）★

3.4 Underlay 监控（三）：路由表（RIB）健康度

用 IP-FORWARD-MIB（RFC 4292）观测路由表的整体健康度， 它是判断 "Stale RIB" 的最直接证据。

3.5 Control Plane 监控：LISP 终端定位系统

OID 全部来自您上传的 LISP-MIB（IETF RFC 7052）和 CISCO-LISP-EXT-MIB。

3.5.1 LISP 角色与特性状态

3.5.2 LISP 全局统计（控制平面流量）

3.5.3 ★ EID 注册状态（Map-Server 视角，最关键）★

3.5.4 Map-Cache 健康（ITR 视角）

3.5.5 Map-Server / Map-Resolver 可达性

3.5.6 ★ Cisco LISP 扩展 Trap（事件驱动黄金组合）★

3.6 Overlay 监控：VXLAN 隧道与 VNI 状态

VXLAN 是 SDA 数据平面的承载协议，每个虚拟网络（租户）映射到一个 VNI（24-bit）。 OID 来自您上传的 CISCO-NETWORK-VIRTUALIZATION-OVERLAY-MIB。

3.6.1 VNI 配置与状态

3.6.2 ★ VTEP 邻居（VXLAN Peer）状态 ★

3.6.3 VXLAN 流量统计（VNI 维度）

3.7 一图看懂：SDA 故障传播链路

图 3-2 · SDA 故障从硬件到业务的传播时间线。监控的目标，是把告警发现压缩在 60 秒之内。

3.8 Zabbix 实战：SDA 三层模板与触发器矩阵

触发器矩阵（按场景分级）

关键 Item 配置示例（YAML 化）

# ========== Underlay · ISIS ==========
- key: isis.adj.state[{#SYSID}]
  oid: 1.3.6.1.4.1.9.10.118.1.6.1.1.2.{#CIRCIDX}.{#ADJIDX}
  interval: 30s
  preprocessing: discard_unchanged_with_heartbeat:300s
  triggers:
    - {prio: P0, expr: "last() <> 3"}

- key: isis.overload[{#LEVEL}]
  oid: 1.3.6.1.4.1.9.10.118.1.2.1.1.4.{#LEVEL}
  interval: 60s
  triggers:
    - {prio: P1, expr: "last() = 4"}

# ========== Underlay · BFD ==========
- key: bfd.state[{#SESSID}]
  oid: 1.3.6.1.4.1.9.10.137.1.2.1.1.6.{#SESSID}
  interval: 30s
  triggers:
    - {prio: P0, expr: "last() <> 4"}

# ========== Control Plane · LISP ==========
- key: lisp.ms.state[{#MS_LEN}.{#MS_ADDR}]
  oid: 1.3.6.1.2.1.220.1.12.1.3.{#MS_LEN}.{#MS_ADDR}
  interval: 60s
  triggers:
    - {prio: P0, expr: "last() <> 1"}

- key: lisp.eid.registered[{#EID_LEN}.{#EID}]
  oid: 1.3.6.1.2.1.220.1.9.1.5.{#EID_LEN}.{#EID}
  interval: 60s
  triggers:
    - {prio: P1, expr: "last() = 2"}

- key: lisp.mapcache.size[0]
  oid: 1.3.6.1.2.1.220.1.1.1.1.9.0.0
  interval: 60s

# ========== Overlay · VXLAN ==========
- key: vtep.peer.uptime[{#PEER_LEN}.{#PEER_ADDR}]
  oid: 1.3.6.1.4.1.9.9.820.1.1.3.1.3.{#NVE_ID}.{#PEER_LEN}.{#PEER_ADDR}
  interval: 60s
  triggers:
    - {prio: P1, expr: "last() = 0"}

SNMP Trap 接收清单（事件驱动核心）

! 在 Catalyst 9300/9500 上启用 SDA 关键 Trap：
snmp-server enable traps isis
snmp-server enable traps bfd
snmp-server enable traps cisco-lisp           ! 启用 LISP 扩展 Trap

! Zabbix 侧 snmptrapd 关注的 OID：
! Underlay
1.3.6.1.4.1.9.10.118.0.17  → ciiAdjacencyChange       (ISIS 邻居状态变化)
1.3.6.1.4.1.9.10.118.0.1   → ciiDatabaseOverload      (LSP DB 过载)
1.3.6.1.4.1.9.10.137.0.2   → ciscoBfdSessDown         (BFD 失联)

! Control Plane
1.3.6.1.4.1.9.9.825.0.4    → clispExtUseMapServerStateChange    ★
1.3.6.1.4.1.9.9.825.0.1    → clispExtUseMapResolverStateChange  ★
1.3.6.1.4.1.9.9.825.0.3    → clispExtMappingDatabaseEidRegFailure ★
1.3.6.1.4.1.9.9.825.0.6    → clispExtEidRegSiteAllRegistrationsExpired

3.9 SDA 监控盲区自查清单

在 SDA 网络里，"端口 Up" 只是序章，
ISIS 邻居、LISP 注册、VXLAN 隧道才是真正决定业务生死的三条命脉。

→ 下一章，我们将回到设备本身：
网元基础健康监控（CPU / Memory / Fan / Power / Temperature）， 看 Cisco 私有 MIB 如何精准捕获每一个传感器的呼吸。

Chapter Four · 设备的体检报告

当一台交换机"看起来还活着"

第二章我们讨论了端口的物理层"咳嗽"，第三章我们读懂了 SDA 协议栈的"血压心跳"。
但还有一类盲区——设备本身的脏腑健康。
CPU 持续 95%、内存碎片化、风扇坏掉一台、电源在抖、传感器温度爬升……
这些都不会让端口 Down，但会让设备慢慢死去，直到某一天突然崩溃。

4.1 CPU 监控：从总体到每个核心

所有 OID 来自您上传的 CISCO-PROCESS-MIB。

4.1.1 CPU 总体利用率（cpmCPUTotalTable）

4.1.2 CPU 负载均值（Linux-style Load Average）

4.1.3 ★ Per-Core 利用率（cpmCoreTable，多核 SoC 必看）★

4.1.4 ★ Per-Process 利用率（cpmProcessExtRevTable，深度诊断必备）★

4.1.5 CPU 阈值告警与 Trap

CISCO-PROCESS-MIB 提供了内置的 CPU 阈值机制， 可以让设备自己判断"超过阈值持续多久"再发 Trap，避免 NMS 反复轮询。

4.2 内存监控：不只是"用了多少"

4.2.1 内存池状态（CISCO-MEMORY-POOL-MIB）

4.2.2 内存利用率（移动平均）

4.2.3 内存 Trap

• ciscoMemoryPoolLowMemoryNotif · 1.3.6.1.4.1.9.9.48.2.0.1 · ★ 低内存告警（携带 PoolName + Used 字节数）★
• ciscoMemoryPoolLowMemoryRecoveryNotif · 1.3.6.1.4.1.9.9.48.2.0.2 · ★ 低内存恢复 ★

4.3 FRU 监控：风扇 / 电源 / 模块的"现场体检"

FRU（Field Replaceable Unit）是可在现场更换的硬件单元—— 风扇托盘、电源模块、线卡、SFP 光模块等。 OID 来自您上传的 CISCO-ENTITY-FRU-CONTROL-MIB。

4.3.1 ★ 风扇状态（cefcFanTrayStatusTable）★

4.3.2 ★ 电源状态（cefcFRUPowerStatusTable）★

cefcFRUPowerOperStatus 的 12 种状态值含义：

4.3.3 模块状态（cefcModuleTable）

4.3.4 ★ FRU Trap（事件驱动黄金）★

4.4 传感器监控：温度、电压、光功率（DOM）的实时呼吸

CISCO-ENTITY-SENSOR-MIB 提供了一个统一的传感器抽象—— 无论是温度、电压、电流、转速、还是光模块的 Tx/Rx Power、模块温度、Bias 电流， 都可以通过同一个表格查询。这是L0 物理层监控的"百宝箱"。

4.4.1 传感器值（entSensorValueTable）

4.4.2 传感器阈值（entSensorThresholdTable）

★ 关键 Trap：entSensorThresholdNotification ★

• entSensorThresholdNotification · 1.3.6.1.4.1.9.9.91.2.0.1 · ★ 任意传感器突破阈值（携带阈值与当前值）★

4.4.3 SFP / DOM 监控的特殊用法

对于光模块（DOM/DDM）的监控，建议结合 ENTITY-MIB 的 entPhysicalClass = sensor(8) 和 entPhysicalDescr 来识别传感器语义：

• "Tx Power Sensor" + entSensorType = specialEnum(13) → 光发射功率（dBm × 10000）
• "Rx Power Sensor" + entSensorType = specialEnum(13) → 光接收功率（dBm × 10000）
• "Temperature Sensor" + entSensorType = celsius(8) → 模块温度
• "Bias Current Sensor" + entSensorType = amperes(5) → 激光器偏置电流

4.5 ENTITY-MIB：所有传感器/模块/FRU 的"户口本"

ENTITY-MIB（RFC 4133）是所有 Cisco 私有 MIB 的"基础索引"—— entPhysicalIndex 是 CPU、内存、风扇、电源、传感器、模块的统一身份证。

配置变更追踪（CISCO-CONFIG-MAN-MIB）

4.6 StackWise 监控：堆叠环的"心电图"

Catalyst 9300 系列广泛使用 StackWise 堆叠技术——多台设备物理堆叠成一个逻辑设备。 堆叠环断裂、堆叠成员降级、堆叠端口劣化都是关键监控点。 OID 来自您上传的 CISCO-STACKWISE-MIB。

堆叠 Trap

• cswStackPortChange · 1.3.6.1.4.1.9.9.500.0.1 · 堆叠端口状态变化
• cswStackNewMaster · 1.3.6.1.4.1.9.9.500.0.2 · ★ 新 Master 选举（说明原 Master 挂了）★
• cswStackRingRedundant · 1.3.6.1.4.1.9.9.500.0.4 · ★ 堆叠环冗余状态变化 ★
• cswStackNewMember · 1.3.6.1.4.1.9.9.500.0.5 · 新成员加入
• cswStackMemberRemoved · 1.3.6.1.4.1.9.9.500.0.6 · 成员被移除

4.7 一图总览：网元健康度仪表盘

图 4-1 · 网元健康度的 5 大维度与综合评分公式。

4.8 Zabbix 实战：网元健康度模板与告警矩阵

告警矩阵（含 5 维度分级）

关键 LLD（自动发现）配置

# LLD 1: 自动发现所有 Sensor
- name: "Discover Cisco Sensors"
  snmp_oid: "discovery[
      {#ENT_IDX}, 1.3.6.1.2.1.47.1.1.1.1.7,
      {#ENT_DESCR}, 1.3.6.1.2.1.47.1.1.1.1.2,
      {#SENSOR_TYPE}, 1.3.6.1.4.1.9.9.91.1.1.1.1.1,
      {#SENSOR_SCALE}, 1.3.6.1.4.1.9.9.91.1.1.1.1.2,
      {#SENSOR_PRECISION}, 1.3.6.1.4.1.9.9.91.1.1.1.1.3
  ]"
  filter:
    - {macro: "{#SENSOR_TYPE}", operator: "MATCHES_REGEX", value: "^(8|3|4|5|6|13)$"}

# LLD 2: 自动发现所有电源
- name: "Discover Power Supplies"
  snmp_oid: "discovery[{#PS_IDX}, 1.3.6.1.4.1.9.9.117.1.1.2.1.2]"

# LLD 3: 自动发现所有风扇
- name: "Discover Fans"
  snmp_oid: "discovery[{#FAN_IDX}, 1.3.6.1.4.1.9.9.117.1.4.1.1.1]"

# LLD 4: 自动发现 Top N CPU 进程
- name: "Discover Top CPU Processes"
  snmp_oid: "discovery[{#PID}, 1.3.6.1.4.1.9.9.109.1.2.1.1.2,
                       {#PNAME}, 1.3.6.1.4.1.9.9.109.1.1.1.1.2.2]"
  filter:
    - {macro: "{#PNAME}", operator: "MATCHES_REGEX", value: ".*(BGP|OSPF|ISIS|LISP|IP Input|SNMP).*"}

SNMP Trap 接收清单（事件驱动核心）

! Cisco IOS-XE 启用关键 Trap：
snmp-server enable traps cpu threshold
snmp-server enable traps memory bufferpeak
snmp-server enable traps entity-sensor threshold
snmp-server enable traps entity-fru-control
snmp-server enable traps stackwise
snmp-server enable traps config

! Zabbix 关注的 Trap OID：
1.3.6.1.4.1.9.9.109.2.0.1   → cpmCPURisingThreshold     ★
1.3.6.1.4.1.9.9.48.2.0.1    → ciscoMemoryPoolLowMemory  ★
1.3.6.1.4.1.9.9.91.2.0.1    → entSensorThresholdNotif   ★
1.3.6.1.4.1.9.9.117.2.0.1   → cefcModuleStatusChange    ★
1.3.6.1.4.1.9.9.117.2.0.2   → cefcPowerStatusChange     ★
1.3.6.1.4.1.9.9.117.2.0.6   → cefcFanTrayStatusChange   ★
1.3.6.1.4.1.9.9.500.0.4     → cswStackRingRedundant     ★
1.3.6.1.4.1.9.9.500.0.2     → cswStackNewMaster         ★ (灾难信号)
1.3.6.1.4.1.9.9.43.2.0.1    → ciscoConfigManEvent       (审计)

监控网元，要像中医把脉——
不是看哪根线断，而是听气血、听脏腑、听节律。

→ 最后一章，我们将把前四章的所有 OID、Trap、阈值整合成
Zabbix 实施路线图—— 从模板设计、分层告警、到团队协同的完整工程方法论。

Chapter Five · 从认知到行动

把 OID 变成 SLA：6 周实施路线图

前面四章我们建立了完整的认知体系——分层 · 多维 · 变化。
但认知不会自动转化为运维能力。这一章，我们把所有 OID、Trap、阈值
凝练成一份可执行的 6 周工程计划， 让每一行代码、每一个告警，都精确指向 SLA 提升的目标。

5.1 总体架构：分层模板 + 双通道采集

图 5-1 · Zabbix 监控架构。双通道采集 + 4 套分层模板，覆盖前 4 章所有监控点。

5.2 6 周实施甘特图：从奠基到智能

图 5-2 · 6 周实施甘特图。3 个里程碑（M1/M2/M3）作为强制 Gate，确保每阶段质量。

5.3 每周交付物清单（可直接落地）

5.4 团队角色与协同矩阵

5.5 ROI 测算：监控提升 SLA 的量化价值

以一家中型制造业园区（200 台 Cisco 网络设备）为例：

5.6 持续治理：让监控系统不退化

监控系统最大的敌人不是技术，而是"熵增"—— 告警越积越多、阈值越来越宽、运维越来越麻木。 用以下三条治理纪律保持系统的"年轻态"：

1. 月度告警噪声审查： 统计 Top 10 告警源（按设备 + 触发器维度）， 若某条告警一个月内触发 > 100 次但都是误报，必须降噪或重新设计阈值。
2. 季度 OID 失效检查： IOS-XE 升级后某些私有 OID 可能弃用。 每季度跑一次全 OID Walk 测试，发现"返回空值"的 OID 立即排查。
3. 半年度阈值再校准： 网络业务量在变，去年的"正常"可能今年就是"异常"。 基于过去 6 个月的实际数据重新计算 P95/P99 分位数，作为新的告警阈值。

监控不是项目，而是一种持续的纪律。
网络在变，业务在变，监控也必须随之进化。

Closing · 回到开篇的那个问题

监控系统从未告警，意味着一切正常吗？

读完这五章，您应该已经有了答案：
恰恰相反。

监控系统的"沉默"，可能是因为我们看错了维度、采错了粒度、漏掉了变化率。
Downshift 不告警，因为我们只看 ifSpeed 不看 ifHighSpeed。
Stale RIB 不告警，因为我们只看 ISIS 邻居却不联动 RIB Age。
光纤老化不告警，因为我们只看绝对值却没建立基线。

真正成熟的监控，是用最少的观测点， 在最早的时间窗，发现最隐蔽的趋势。

网络监控的尽头，不是堆砌指标，
而是让设备主动告诉你它需要什么。

↑ 回到第一章 · 重新开始这场旅程

Glossary · 术语表

关键术语速查

按字母顺序排列，含中英文对照与一句话定义。所有术语均出自前 5 章正文。

© 2026 · Cisco Network Observability Whitepaper · 基于 IETF / IEEE / Cisco MIB 真实 OID · 编写于