百度网络监控实战:NetRadar横空出世(上)

作者简介

运小贝    百度高级研发工程师 

负责百度内网质量监测平台(NetRadar)的业务端设计及开发工作。在系统和网络监控、时序指标异常检测、智能客服机器人等方向有广泛实践经验。

干货概览

百度内网连接着数十万台服务器,承载着全公司业务的网络通信,其通信质量的重要性不言而喻。而百度内网的质量监测平台NetRadar(网络雷达),通过对整个内网“服务器端到端”传输质量进行监测,实现了快速、准确地发现、通告、定位内网问题,为百度业务的正常通信提供了有力保障。

《百度网络监控实战:NetRadar横空出世》系列文章将分上、下两篇介绍NetRadar平台,本文主要介绍内网质量监测的意义、相关需求以及百度原有的内网监测技术,而下篇将从核心功能、设计框架、异常检测策略以及可视化视图等方面对NetRadar平台进行系统介绍。

 

百度内网介绍

百度拥有数十万台服务器,分布于全国各地的几十个数据中心(又称IDC、机房)。这些海量的服务器通过网络分层级互联,构成了统一的“资源池”,对外提供可靠、强大的存储、计算和通信服务。

在软件架构上,百度的大型服务一般都是模块化设计,一次服务需要上下游大量模块共同协作完成。为了提高并发服务能力和容灾能力,这些模块会分布式地部署在不同机房的不同服务器上。为保证服务的正常运行,内网必须保证各模块具有良好的“端到端”网络通信能力,一旦出现网络故障并影响了模块间的通信,往往会对服务造成影响,甚至导致服务整体不可用。

为了提供高可靠、高性能的端到端通信能力,网络结构在设计上预留了大量冗余,既有设备的冗余,也有线路的冗余。这样一来,两台服务器间的通信可以同时存在许多条不同的路径,能够在一定程度上抵御网络故障。尽管如此,实际环境中端到端的通信问题依然常见,其原因主要包括:路由收敛延迟、ToR交换机单点故障、网络拥塞等等。另一方面,即便单个设备、网线、服务器发生故障的概率很低,乘上巨大的数量,故障必然是“常态”现象。

在这种“与故障为伴”的环境下,既然无法避免故障,就需要能够及时、准确地监测内网质量,这对于保证服务正常运行来说是至关重要的。

需求调研

在运维实践中,工程师对内网质量监测系统都有什么样的需求呢?我们对各业务线的运维工程师,以及来自网络组的同学进行了调研。为了更好地说明用户需求,图1给出了一个典型的运维场景:

当运维工程师发现服务关键指标异常后,如果怀疑是内网故障导致的,则需要通过回答如下一些问题进行排查:
 1)“机房A到机房B的网络有问题吗?”
 2)“服务器a到服务器b网络有问题吗?”

如果经过检查确认内网没有问题,就要继续排查其他可能的原因,诸如上线、操作、程序 bug 等原因,以帮助进行有效的止损和恢复决策。而如果确定是内网故障导致服务受损,那么网络工程师为了诊断和修复网络故障,会排查一系列的通信问题来帮助缩小故障范围,比如:“哪些服务器通信有问题?”,“哪条链路有问题?”等。为了回答这些问题,最直接有效地方式就是“进行服务器端到端检测”,比如:

   1) 排查“机房A到机房B网络有问题吗?”

        可以测试: 机房A大部分机器到机房B大部分机器间的网络质量

   2) 排查“机房A内部网络有问题吗?”

       可以测试: 机房A大部分机器互相访问的网络质量
   3) 排查“服务器a到服务器b网络有问题吗?”

       只需测试: 服务器a访问服务器b的网络质量

   4) 排查“哪些服务器通信有问题?”

       需要挨个ping或ssh疑似有问题的服务器
   5) 排查“在哪条链路上出的问题?”

       需要执行traceroute命令查看路由细节

但是,人工执行上述测试任务费时又费力。如图2所示,为了进行一次端到端的网络质量检测,首先要确定“源-目的”服务器,然后获得服务器的登录权限,之后才能登录到机器上执行各种测试操作,最终分析数据得到测量结果。显然,这种人工测量的方式可扩展性很差,无法应对大规模测量的需求。因此,需要一个平台能够实时地、自动地执行测量任务,给出分析结果。

那么,这个平台需要满足什么要求呢? 通过对业务线运维工程师和网络工程师进行调研,整理的需求如下:

 1)“端到端”的持续监测

由于百度业务线的程序或模块均部署在服务器上,其网络通信也都是从服务器发起和接收,所以服务器“端到端”的网络质量更能反应内网状况对业务通信的实际影响。所以从业务角度出发,平台应当能够对端到端网络质量进行持续监测。

 2)全覆盖的监测

实际中,运维工程师通常知道业务部署在哪些机房,但不清楚具体哪些机器间有网络通信,所以会关注 “这些机房网络是否正常”这种全局性的问题。此外,网络工程师的责任是保证整个内网质量可靠,需要系统地监测整个内网性能,尽可能地发现和修复网络故障,减少隐患。 

 3)按需下发监测任务

实际工作中常常需要根据现场情况执行特定的监测任务,这导致需要进行额外的、有针对性的测量。所以,监测平台还需支持按需监测。

 4)检测结果主动报警

由于网络工程师直接对内网质量负责,因此希望监测平台在测量”端到端”通信性能后,对相关数据进行分析,判断网络是否正常,并在检测到网络异常后及时发送报警,以保证各业务线服务正常。

 5)针对产品业务的定制化展示

由于一个产品业务通常只部署在部分机房,依赖部分网络,所以运维工程师往往不关注非其负责的。因此,监测系统需要支持定制化展示,使运维工程师能迅速获取其需要关注的网络状态信息。

那么,百度现有的内网监测技术能否满足以上需求呢?

现有监测技术

其实,百度内部已经应用了一些内网质量监测技术,这些技术利用不同的测量手段获取内网质量数据,并加以分析,进而判断网络是否正常。表1给出了三种现有监测技术的相关信息。

编号

监控原理

不足

技术1

利用交换机的Syslog监测交换机级别故障 

交换机级别故障无法准确反映业务所感知的网络性能

Syslog无法记录所有交换机故障

无法检测非交换机故障类网络异常

技术2

部署专用的服务器探针来连接各IDC核心交换机,服务器通过互相发包对IDC间网络性能进行主动探测

IDC内部网络通信监控缺失

探测到的IDC间网络性能和业务感受到的网络性能有所差别

资源开销大,不能直接扩展

技术3

在所有线上服务器部署探针,并在各IDC分别设置一个靶标服务器,让所有线上服务器测量到各靶标服务器的网络状态

单个靶标服务器存在单点故障问题,不能很好代表机房的网络情况

机房内部的拓扑覆盖不全

不支持按需探测功能

 

上述几种技术在内网质量监测和运维中发挥了一定作用,但在使用过程中也发现了一些不足,不能很好满足上述需求。因此,基于以上技术的实战经验,我们开发了新平台NetRadar(网络雷达)。与以上监测技术相比,NetRadar具有以下优点:

覆盖广探测agent在全网linux服务器完成部署,覆盖了百度全部内网机房;

多层级7*24小时持续监测整个内网的网络质量,包括机房间、机房内集群间、集群内ToR交换机间的网络质量;

指标全评价网络质量的方式多样,区分QOS队列、协议、统计值,共计27种网络质量监控指标,每个探测周期会产生近百万的监控指标;

检测准通过自适应异常检测算法对监控指标进行检测,并进一步生成机房、区域级别的网络事件;

除此之外,NetRadar还支持按需探测,并提供全内网“端到端”探测接口以及故障事件接口,以帮助工程师快速诊断网络问题。

总结

相信通过本文的介绍,您已经对百度内网质量监测有了一些了解。接下来,我们将推出本系列文章的下篇:《百度网络监控实战:NetRadar横空出世(下)》,系统性地介绍NetRadar平台,请持续关注AIOps智能运维!

若您有其他疑问或者想进一步了解NetRadar平台,欢迎留言反馈!

智能运维时代,AIOps智能运维与您同行!

收藏 评论(1)
分享到:
共1条回复 最后由enjoyfdgertert 回复于2019-10-21 00:09
#2 enjoyfdgertert 回复于2019-10-21

很有收获 感谢楼主

本回复来http://wtwinkle.wikidot.com网页提供

0