1. 课程导入与可观测性框架

在传统园区网运维中,我们习惯用 SNMP 轮询去“看”设备:每隔 1 分钟或 5 分钟向交换机、无线控制器、路由器发一次 OID 查询,把 CPU、内存、接口流量、错包计数拉回网管平台。这套方法在设备数量少、业务变化慢的年代足够用,但当 Cisco Catalyst 网络承载起 Wi-Fi 6/7、SD-Access 分段、IoT 接入和云边协同流量后,轮询的粒度、延迟和覆盖面都开始捉襟见肘。本章要建立的,是一套面向 Catalyst 环境的可观测性框架,并明确它与传统 SNMP 运维的差异,以及后续 29 章要落地的实战目标与拓扑环境。

一、可观测性三支柱在 Catalyst 中的定位

可观测性不是“多采集一些数据”,而是通过三类互补信号回答“系统现在怎么样、为什么变成这样”。在 Cisco Catalyst 环境中,这三支柱有非常具体的落点:

  • 指标(Metrics):随时间变化的数值序列。Catalyst 上典型来源包括接口收发速率、CRC/错包、队列丢弃、CPU 5 秒/1 分钟/5 分钟利用率、内存池占用、PoE 功率、无线 AP 关联客户端数、CAPWAP 隧道时延等。指标回答“是否异常、异常多大”。
  • 日志(Logs):离散的、带时间戳的事件记录。Catalyst 上包括 syslog、%LINK-3-UPDOWN、%SW_MATM-4-MACFLAP_NOTIF、%DOT1X-5-FAIL、AP 掉线、RADIUS 超时等。日志回答“发生了什么事件”。
  • 追踪(Traces):一次请求或一条流在网络中经过的路径与各跳耗时。Catalyst 上可通过 ERSPAN、NetFlow/IPFIX、模型驱动遥测中的流表、以及 Catalyst Center 的路径追踪来获得。追踪回答“问题出在哪一跳、哪一段”。

三者不是并列堆叠,而是有层次的:指标先发现异常,日志给出事件线索,追踪定位到具体设备与接口。缺少任何一支,排障都会退化成“猜”。

二、遥测运维与传统 SNMP 轮询的差异

传统 SNMP 是“拉模型”:网管主动轮询,设备被动应答。它的核心限制是采样周期长、粒度粗、且轮询本身消耗设备 CPU。模型驱动遥测(Model-Driven Telemetry,MDT)是“推模型”:设备按订阅周期主动把数据推给采集器,周期可到秒级甚至亚秒级,数据以 YANG 模型结构化编码(如 JSON、GPB)。

对比维度SNMP 轮询模型驱动遥测
数据方向网管拉取设备推送
典型周期60~300 秒1~30 秒,可更短
数据格式OID + 标量YANG 结构化,含层级与键
设备开销轮询越密开销越大订阅固定,开销可预期
适用场景趋势与容量微突发、快速故障定位

需要强调:遥测不是要彻底取代 SNMP。容量规划、资产盘点、低频健康检查仍可用 SNMP;而微突发、队列抖动、快速收敛过程,必须靠遥测。两者是互补关系。

三、实战目标与拓扑环境

本课程后续章节将围绕一个可复现的 Catalyst 实验拓扑展开。拓扑包含:一台 Catalyst 9000 系列核心交换机作为边界与遥测源,两台 Catalyst 9200/9300 作为接入,一台 Catalyst 9800 无线控制器管理若干 AP,一台运行采集与可视化组件的 Linux 服务器。核心与接入之间为 Trunk,接入下挂终端与 AP,核心上联到采集服务器所在网段。

实战目标分四层:第一,能在 Catalyst 上启用并验证模型驱动遥测订阅,把接口与 CPU 指标推到采集器;第二,能配置 syslog 与 NetFlow/ERSPAN,形成日志与追踪数据;第三,能在采集侧完成指标、日志、追踪的关联查询;第四,能基于三支柱完成一次从“指标异常”到“定位到具体接口与事件”的闭环排障。

建议在实验前先确认 Catalyst 的 IOS-XE 版本支持 telemetry 与 YANG 模型,并记录设备管理地址、采集器地址与订阅端口,后续章节会反复使用这些参数。
Catalyst 可观测性三支柱与遥测数据流 指标 Metrics 接口速率 / 错包 / 队列丢弃 CPU / 内存 / PoE / AP 关联数 回答:是否异常、异常多大 日志 Logs syslog / LINK-UPDOWN MACFLAP / DOT1X / AP 掉线 回答:发生了什么事件 追踪 Traces ERSPAN / NetFlow / IPFIX 路径追踪 / 逐跳耗时 回答:问题在哪一跳 采集与关联层(Telemetry Collector + 日志平台 + 流分析) 按时间戳与设备/接口键关联三支柱数据 Catalyst 9000 核心 遥测源 / 边界 Catalyst 9200/9300 接入交换机 Catalyst 9800 无线控制器 + AP 采集服务器 Linux + 可视化 遥测推送 syslog NetFlow 指标发现异常 → 日志给出事件 → 追踪定位到具体设备与接口

四、从“看得到”到“说得清”

很多团队上了遥测后,数据量暴涨,但排障效率没有提升,原因是只做了采集、没做关联。可观测性的关键动作是:当接口错包指标在 10:23:15 突增时,系统能自动拉出同一时间窗内该接口的 syslog 事件,以及经过该接口的流追踪记录。这要求三支柱数据在采集侧共享统一的设备标识、接口标识和时间基准。

在 Catalyst 上,建议统一使用设备 hostname 或序列号作为设备键,使用 ifName(如 GigabitEthernet1/0/1)作为接口键,所有采集组件通过 NTP 与同一时间源同步。这样,指标、日志、追踪才能被“拼”成一条完整的证据链。

如果设备时间不同步,指标时间戳与日志时间戳可能相差数秒甚至数分钟,关联查询会直接失效。实验前务必确认所有 Catalyst 与采集服务器已同步 NTP。

五、本课程的学习路径

后续章节将按“框架认知 → 数据采集 → 数据关联 → 场景排障 → 运维闭环”推进。你会先掌握 Catalyst 上遥测订阅的配置与验证,再学习日志与流数据的采集方法,然后进入指标、日志、追踪的关联分析,最后通过微突发、无线漫游、认证失败等真实场景完成闭环演练。每一章都会给出可复现的配置片段、参数示例与判断依据,确保你不仅“知道”,而且“做得出、看得懂、判得准”。

本章的核心结论只有一句:在 Catalyst 网络中,可观测性不是单一工具的堆叠,而是指标、日志、追踪三支柱在统一时间与标识下的协同。遥测运维解决了“采得细、采得快”的问题,但只有把三支柱关联起来,才能真正把“看得到”变成“说得清”。