03-数据为王,高歌猛进的Telemetry

4.3.1据为王，高歌猛进的Telemetry第二章中，我们提到汽车自动驾驶对网络运维的启发，业界针对自动驾驶汽车定义了三层系统架构，包括Sensor、分析+控制和云平台。底层的Sensor作为数据的来源，通过雷达、微波、激光等多种类型的传感器，精准地感知周边路况信息，基于这些信息，汽车可以对前方的急刹车、横穿马路的行人、上下坡等各种情况做出精确的反应。那么对于电信行业的自动驾驶，在其三层智能的系统架构中，同样也需要在物理网络层构建一个能实时感知态势的"Sensor”，将面向网络和业务级应用的真实数据实时上报，为上层预测性运维和主动闭环优化提供数据基础。那么对于自动驾驶网络，什么样的"Sensor”更合适？先来看一个例子，2018年世界杯，运营商A的IPTV视频直播频发卡顿和模糊。众所周知，用户对直播视频的流畅度要求极高，往往几秒钟的卡顿就会影响到用户对直播观看的体验，重复发生必然会影响其IPTV的品牌影响力，导致用户流失。那么作为直播视频的运营商，应该如何对秒级卡顿问题进行感知分析，自动调整网络配置，主动闭环优化，保证用户观看体验呢？对秒级卡顿的感知，首先必须获取到秒级/亚秒级的网络质量数据，做到实时的大数据上报。然而我们知道，传统网络运维模式以设备为中心，常用的数据采集方式，例如SNMP，采集周期为5分钟，过大的采集周期，会导致细节信息丢失，无法支撑秒级卡顿的自动优化闭环。例如图1,正常的接口带宽变化是如下的红色线条，但SNMP定期查询采集到的却是风平浪静的绿色线条，无法发现圆圈标识的流量异常下降。H：=J图1H：=J图1接口带宽监控曲线那么采集周期可以缩短，从而实现实时采集吗？传统SNMP是拉模式(PullMode)的"请求-回答”式交互，每次采集数据都需要网管发起查询请求，设备解析请求后再响应上报数据。就像按压式抽水泵一样，压一下出一点水。采集效率低，无法做到实时采集。

图2图2按压式抽水泵而且数据模型的兼容性也差，例如SNMP基于MIB数据模型，由各厂商自定义。也就是说如果网管系统要管理其他厂商的设备，可能需要花很大力气去学习该厂商的MIB模型。网络自动驾驶需要更标准的数据模型，提升运维效率，所以传统SNMP不适合做自动驾驶网络的"Sensor”。从上面的举例和传统采集方式的问题中，我们可以窥探出自动驾驶网络"Sensor”的选择标准：基于标准的数据模型，实时大数据上报，实时感知，洞察业务细节。Telemetry技术应运而生在前面的章节里，我们讲过YANG，基于这个不断完善的标准数据模型，和Google提出的gRPC传输协议，Telemetry技术应运而生。QpenCflnfiflfiEff仁也女心miItMtrcwf:5**KT.FLwslil〕CC^L伽罚心！•刑1T■-Bellq. KDfLII OT?gw2005年，Google提出gRPC（Telemetry使用的传输协议）供内部使用，至2015年，Google公开gRPC,主导成立了OpenConfig组织，包含领先的互联网厂商和运营商，例如BT,AT&T,SKT,Telefonica,ORACLE,MicrosoftQpenCflnfiflfiEff仁也女心miItMtrcwf:5**KT.FLwslil〕CC^L伽罚心！•刑1T■-Bellq. KDfLII OT?gw■Google主导！:K立0penConfig^gfR-OpenConhg^YANG模里-ItlF发布YANG栏型 Nowj I•Googlet根出#RPC ・Telem翩ry标推进一步完善•基与1」口=＞何.*击式上送机制图3Telemetry发展历史

Telemetry是一项远程的从物理设备或虚拟设备上高速采集数据的技术。设备通过推模式（PushMode）周期性的主动向采集器上送设备的接口流量统计、CPU或内存数据等信息，而不是被动的等待采集器定时查询。避免查询请求在网络传输中的延迟和大量查询请求对网络和设备带来的压力，提升监控性能。相对传统拉模式（PullMode）的一问一答式交互，提供了更实时更高速的数据采集能力。来看看推模式是怎么样的？箔求CPU占用率③订阅CPU占用率.碘1秒京嗽解析请求瞄CPUS用率iijiS^CPU占用率（幻懂收CPU占用率口； R浦柬CPU占用率：n）■ 撞收CPL」占用击问 1-T-Simin接咆CPUL亍用率J§4fcCPU：7.i|l^（2）接iftCPU占用笔（为接收CPU占用率｛n） ■阐培设窗网建设督EMS/NMST=ls传验SNMPTiclcimetry图4传统的拉模式和Telemetry推模式对比（T：采集周期）传统拉模式（例如SNMP）的查询与设备之间是一问一答的交互。每次下发查询请求，设备都需要解析请求报文，即n次查询请求、n次解析请求。而Telemetry的推模式，它只需要1次订阅请求和1次解析请求，就可以按照订阅指定周期持续推送数据给网管。采用推模式就可以做到实时采集了吗？答案是否定的，Telemetry是一个特性，需要一系列技术的配合。Telemetry技术的采样数据源来自网络设备，数据按照通用的结构化数据模型YANG进行组织，利用GPB极简格式编码，并通过gRPC或UDP协议将数据快速上送至采集器，供分析器进行分析处理。图5Telemetry框架这样我们拿订餐比喻数据采集，介绍以上技术的优势，理解下Telemetry与传统采集方式的差异，为什么可以做到实时采集。

有位NCE太太独自居住，不喜爱做饭，经常需要订餐。」日叫传统的SNMP餐厅是怎么订餐的？首先他们的MIB菜单上的字是本地化的，需要翻译学习后才能看懂（数据模型自定义，需要定制适配），而下单的过程是这样的：Hello,请尊送T■两红秘曙蜀好㈤,f西红柿鸡真WCF西红牡妙耙军愉好店酣误拾TNCEA ［拄程式一间二客变质）WCF请绐我送一个言保蹲丁.好的.f■白保鸡丁.个M保迪丁械H后朗我我了MCI太太.为什么不能一起做好送过来呢，因为SNMP餐厅后厨的人力太少（设备硬件能力和管道传输能力弱），订单太多会处理不过来，所以一次只能订一个菜，送到了再订下一个。这样一顿饭吃下来是不是觉着很累，长期订饭的体验就更差了。那么Telemetry餐厅的体验是怎样的？Telemetry餐厅使用的YANG菜单是全球通用的文字（通用的结构化数据模型），NCE太太可以很快识别。Hello.请站我送一^红柿炒鸡鼠f昌保鸡丁。每天定^配送.为期一个月，（推模式的订阅式采集）好的。〔一次解析） *冬Telemetry餐厅的后厨人力物力充分，并采用GPB方式快速烹饪（极简编码格式），先进的gRPC/UDP快递配送系统（快速传输协议）。从此，NCE太太会源源不断的收到她的订餐。

利用Telemetry技术，智能运维系统可以实时收集到大量的设备数据，将数据交给分析系统进行综合分析、决策后，将决策结果发送给控制器，由控制器调整设备的配置，然后又可以几乎实时的收到调整后设备的状态反馈，整个流程形成闭环。智能运唯系统图6Telemetry在智能运维系统中的应用智能运维系统与各设备建立gRPC通道，在设备上配置Telemetry订阅。各设备通过gRPC通道将订阅数据上报给采集器。采集器接收、存储、加工处理各设备上报的数据。分析器基于大数据分析系统进行分析。控制器下发调优指令对网络进行调优。调优指令下发生效后，新的采