网络监控方案—Telemetry(遥测技术)

1、几种不同采集方式对比：CLI，SNMP，SYSLOG，Telemetry

CLI：

作为应用最广使用最久的网络监控技术，最大的问题就是兼容性，同类产品不同厂商之间的兼容性，甚至同厂商不同版本（比如软件平台切换）之间也会存在差异。
而现网环境下，一般是多厂商设备组网，经常有不同厂商，不同型号设备升级调试，都需要更改运维脚本，而多厂商则意味着需要准备多个不同版本的运维脚本，即使本来是很简单的事情也会变得复杂。

SNMP：

“拉”模式方式需要采集器通过轮询的方式处理每个网元，随着网络规模、采集器以及采集信息的增加，网元需要接受越来越多的查询，因此网元不能的正常工作；
同时因为采用的是“拉”模式，传输时延无可避免，导致监控到的网元数据会进一步失真，只能实现分钟级粒度，远达不到秒级甚至亚秒级的颗粒度。

“推”模式，即Trap上报，但推送数据仅告警和事件，对于接口流量之类的数据，不支持；同时又因为采用的是UDP传输协议，又存在丢包的可能。因此进一步限制了SNMP的发展应用。

Syslog：

长期以来，Syslog的格式是比较随意的。即使有规范格式，但由于规范出的晚很多厂商并没有遵守或不完全遵守。
因此Syslog虽然支持“推”模式，能够在设备产生告警和事件时及时推送数据，但因为推送数据的随意性以及数据主要以告警或事件方式，和SNMP一样对于接口流量信息则力所不及。

Telemetry：

工作模式是推模式，可以主动推送数据，精度是亚秒级。而且比较关键的一点是，Telemetry的数据结构采用采用标准结构和标准编码。方便对接第三方的设备，有助于网络监控的效率的提升和监控质量的提升。

几种方式的对比：

请添加图片描述

2、传统网络采集的问题

请添加图片描述

如下：两次采集之间其实遗漏了很多重要信息

请添加图片描述

传统snmp的不足：

1、推模式使用udp不靠谱：如果刚好端口挂了的那条告警就丢了，那就被遗漏了
2、兼容性差：每家厂商都有MIB库，但是不一定统一
3、性能差：采用一问一答模式，采集窗口通常是分钟级别的，会丢失部分重要峰值信息，如果加大采集频率，则会使网络设备负载高，影响转发性能

3、Telemetry 技术产生背景

随着SDN网络的设备规模日益增大，承载的业务越来越多，用户对SDN网络的智能运维提出了更高的要求，包括监控数据拥有更高的精度以便及时检测和快速调整微突发流量，同时监控过程要对设备自身功能和性能影响小以便提高设备和网络的利用率。

传统网络监控方式（CLI，SNMP，SYSLOG等），因存在如下不足，管理效率越来越低，已不能满足用户需求的演进：

1、通过拉模式来获取设备的监控数据，不能监控大量网络节点，限制了网络增长。
2、精度一般是分钟级别，只能依靠加大查询频度来提升获取数据的精度，但是这样会导致网络节点CPU利用率高而影响设备的正常功能。
3、由于网络传输时延的存在，监控到的网络节点数据并不准确。
4、获取的数据类型有限，可能有些采集方式不支持采集流量情况，只有事件和告警，比如：SYSLOG和SNMP Trap模式

因此，面对大规模、高性能的网络监控需求，用户需要一种新的网络监控方式。Telemetry技术可以满足用户要求，支持智能运维系统管理更多的设备、监控数据拥有更高精度和更加实时、监控过程对设备自身功能和性能影响小，为网络问题的快速定位、网络质量优化调整提供了最重要的大数据基础，将网络质量分析转换为大数据分析，有力的支撑了智能运维的需要。

请添加图片描述

总结一下Telemetry的优势：

采集数据的精度高，且类型十分丰富，可以充分反映网络状况，故障定位更快速、精准。支持一次订阅，持续上报。相比传统网络监控技术的查询一次上报一次，Telemetry仅需配置一次，设备就可以持续上报数据，减轻了设备处理查询请求的压力。可以实现业务端到端的网络流量可视化，打破“网络黑盒”，为精细化网络运维提供整体的解决方案和必要的技术支撑。