订阅业界RSS CSDN首页> 业界

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

发表于2018-04-19 15:05| 来源百度云| 作者运小贝

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

 

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

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

 

1

如何对百度内网及时、准确的监测?

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

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

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

因此,在这种“与故障为伴”的环境下,既然无法避免故障,就需要能够及时、准确地监测内网质量

2

多场景运维需求呼唤新监测平台

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

 

  图1 内网问题相关的运维场景  

当运维工程师发现服务关键指标异常后,如果怀疑是内网故障导致的,则需要通过回答如下一些问题进行排查:

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

 2)“服务器a到服务器b网络有问题吗?”

如果确定是内网故障导致服务受损,则会执行相关预案(如切流量),避开有故障的内网区域,并等待网络故障修复。另一方面,网络工程师为了修复故障,需要执行一系列的排查操作来缩小并定位问题,从而对类似“哪些服务器通信有问题?”,“哪条链路有问题?”的问题有确切的答案。获取答案最直接有效的方式就是“进行服务器端到端检测”,比如: 

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

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

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

可以测试: 机房A大部分机器互相访问的网络质量 

3) 排查“服务器a到服务器b网络有问题吗?”

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

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

需要挨个ping或ssh疑似有问题的服务器

5) 排查“在哪条链路上出的问题?”

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

图2 人工测量网络质量步骤  

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

那么,这个平台需要满足什么要求呢? 通过调研,整理的需求如下:

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

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

 2)全覆盖的监测

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

 3)按需下发监测任务

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

 4)检测结果主动报警

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

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

一个产品业务通常只部署在部分机房,依赖部分网络。向运维工程师展示与其负责的产品业务无关的网络状态不但没有帮助,还可能浪费工程师的时间。因此,监测系统需要支持定制化展示,使运维工程师能迅速获取其需要关注的网络状态信息。

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

3

NetRadar横空出世

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

表1 现有监测技术原理及不足  

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

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

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

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

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

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

 

 

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

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

 

关于作者运小贝  

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

0
0