是一个介绍如何利用思科先进技术解决客户难题的栏目。每期聚焦一个技术热点或应用场景，邀请资深思科技术专家深入浅出地介绍，为读者提供实用性强的建议。

　　前两期我们介绍的基于意图的主动运维系统，已经能让很多传统运维手段凤凰涅盘、迸发出新的生命力，但大数据和人工智能的加持还可让主动运维能力更上一层楼。在《噩梦不再，美梦成真—数据中心智能主动运维》中我们把自动化层所驱动的大数据数据收集模式比喻为交通违章的视频监控，带内遥测 INT MX 相当于车内装摄像头，情况反映真实但能拍到的太少；INT MD 相当于狗仔队跟着你拍，可以全方位无死角但资源消耗太大、实现成本太高。那有没有功能强大但同时又足够轻量化、性价比能保证现阶段端到端部署的 INT 带内遥测方案呢？想想真实世界的交通违章罚单都是被什么样的摄像头拍摄下来的，就能够猜到答案了。

　　

　　不错，上面那样的摄像头才是让老司机们最害怕的，闯个红灯、轧个实线都难逃法眼。INT XD 也是这样的工作方式，由交换机监视来来往往的数据包并向后台实时报告。不过可能你也会有疑问，摄像机对应到真实网络中，岂不是每一个经过交换机的数据包都需要被 “ 拍下来 ” 传到后台，这样就算交换机硬件足够强大，后台的数据也是大到恐怖吧，INT XD 的轻量化优势从何而来呢？其实和真实世界查违章必须定位到具体车辆不同，网络世界里虽然也需要对异常发生的位置、时间和程度等信息掌握得尽可能精确详尽，但完全没有必要定位到具体的某个数据包，只要有足够细粒度的统计信息，大数据平台的AI就能实现诸如故障早期预测、问题的根因分析等智能主动运维功能。这就是 XD 方法的技术核心所在——如何巧妙的设计算法，按批次生成报告而非按每一个包生成报告，从而具备足够的统计细粒度的同时尽可能降低软硬件负担。

　　按时间周期批量化不难做到，利用硬件把周期缩短到每秒生成报告都不成问题。难在如何生成更有统计价值的报告，比如有意义的延迟统计至少需要给出 1 秒内所有包的平均延迟、平均抖动容限、最大最小延迟等，这就需要测量出每一个包的延迟数值来计算，例如对逐跳延迟需要精心设计转发流水线，对每一个包 Ingress 打时间戳，在 Egress 验证时间戳，而对端到端延迟则需要Ingress交换机和 Egress 交换机之间实现高精度时间同步协议（PTP），而这绝大部分都需要内置在转发芯片内，减少 CPU 参与。

　　只在时间上分批次是不够的，因为这样统计出的数据分不出是哪个业务，对改善业务体验没有指导意义。要做业务流区分，有经验的小伙伴一定想到了五元组流表，不错，Cisco 正是利用江湖上久负盛名的 Netflow 流表对所有数据进行批次划分，这样所有的统计都归类到具体的流记录中，从而具备了业务的上下文关联。同样要做到全流量记录，从流表的匹配、数据记录到数据的封装导出，仍然必须都是全硬件化而不能有 CPU 参与。

　　硬件化 PTP、Netflow 这些特性 Cisco 很多年前就已经驾轻就熟的运用于几乎全线的数据中心交换机产品上，因而 INT XD 可以出现在相对低端的接入层设备也就不足为奇了。而没有这些硬件特性的交换机想要实现全时、全路径、全流量提供路径遥测（Path Telemetry）功能，还是只能借助显得重很多的 MD 方式。正如上期提到的，MD 当前只能在相对高端的 12.8T 以上平台实现，绝大部分企业的接入层短期内都不太可能选用。

　　端到端的全时、全流量、全路径的 Path Telemetry 有什么用？让我们回到《网工历险记 - 拿什么拯救你我的头发？》那些让工程师掉头发的运维烦恼中来看看吧，不过这次受影响的不仅是网工，整个IT部门的工程师们都在挠头。

　　这次 IT 部门要对一个现有应用做一次重大升级以便开展一项关键业务。整个升级在测试环境演练多遍，非常成功。然后在难得的变更窗口中做最终的生产上线时却出了大问题，大面积的用户访问异常，网工们 ping 遍了有问题的服务器都没有查到丢包，眼见窗口时间快到了，只好让应用部门回退，幸运的是降级后业务恢复如初，但新业务上线算是失败了。接下来的几天从应用到系统再到网络大家查了个遍，由于变更窗口时的现场已经不复存在，留下来的 log 也查不出任何问题，而不揪出根因谁也不敢贸然再次升级，新业务上线就一直这么搁置着。业务部门当然一直在投诉 IT 不给力，IT 工程师们则一边挠头一边叹息：“ 唉，要有个时间机器就好了，回到问题发生的时候看看到底怎么回事啊。”

　　具有 INT XD 全场景 Path Telemetry 记录功能的大数据平台其实就是这样的时间机器，只要端到端部署了硬件化 XD，用户就可以自建这样的大数据平台，也可以使用Cisco交钥匙的一体化平台 Nexus Insights（NI）系统。下面我们来看看 NI 是怎么解决这个问题的。

　　NI 作为智能 AI 大数据平台，它的数据源除了来自交换机的 INT XD 外，还能够集成第三方的应用性能监测系统，前几期提到过的 Cisco AppDynamics 则是天然支持。所以我们第一时间可以回溯到升级发生的那个时刻查看 NI 所集成的 AppDynamics 信息，果然发现了应用在那个时候的健康出了问题。

　　然后我们点击 AppDynamics 展示面板中出问题的应用，立刻呈现出应用健康值偏低的应用层级（Tier）。

　

　　我们把处于最上游的那个 Tier 的通信连接展开（上游的健康问题很可能是下游问题的根因），它立刻展示出了和这个 Tier 有关的数据流：

　

　　我们只要点击 Browse Network Flow 按钮，所有 INT XD 记录的这个 Tier 的数据流就都会展现在你的面前：

　　这时候我们就可以开始操纵这个 “ 时间机器 ” 了，先把时间调到升级之前：

　　浏览当时升级前正常流量的情况：

　　用同样的方法我们再把时间拉到升级之后看这些流的情况，这套系统忠实的记录了这个流的每一个包在当时的统计状态：

　　咦？怎么升级的前后短短 1 分钟内，流的路径就和以前不一样了。网工们继续挖掘，NI 还智能关联了这 1 分钟里其他的重大异常事件：

　　

　　结果发现了频率非常低、逃过了网络自身检测的不正常 EP 移动，很有可能是间歇性的主机路由回送造成的。于是追查这个回送路由的接口，发现连接着互联网出口防火墙——一个外部防火墙当时在做着内部通信的网关！

　　诊断到此时网工们拍着微秃的脑门已经开始恍然大悟了，原来在正常情况下 Tier 之间通信属于内网通信，会命中数据中心内部网络的分布式网关；去互联网的流量将使用默认路由，指向出口防火墙。在那天升级应用时卸载旧应用组件的步骤会删去一些逻辑网络接口，操作系统会把与之绑定的内部分布式网关的路由也一并移去，而新应用安装后并没有重设这些被自动移除的路由，于是内部业务流量就会命中默认路由，发往了出口防火墙。防火墙本身有指向内部的路由，一般的流量会被路由回来，所以像 ping 这样的检测工具察觉不到丢包，防火墙也不对 trace 提供正确的信息响应，网工们自然查不出异常，但新业务却会因为只有一个方向的流量经过防火墙引起路径不对称而被拦截，导致最终的业务故障。正是因为 NI 有 AppDynamics 辅助对应用层级健康提供洞见，再对自己收集到的全时、全流量、全路径的 Path Telemetry 记录进行针对性聚焦，用户才有机会对当时故障实现全场景复现并找到根因，最终通过修改应用部署脚本让新业务成功上线，IT 部门也凭此卸下业务部门的压力重担，大家都松了口气。

　　数据中心主动运维我们连讲了三期，到此告一段落。限于篇幅，我们仅涉及了 Cisco AIOps 的一小部分，基于意图的主动运维方法论框架以及 Nexus Dashboard / Nexus Insights / AppDynamics 解决方案我们也只浅尝辄止。还是那句老话，欲知详情，请继续关注 “ 思科联天下 ”、“思科渠道微情报 ” 以及思科的 DEVNET 和 dCloud 网站，在那里你不仅可以获取 Cisco AIOps 的详细信息，还可以自己亲手一试。