百度网络监控实战:NetRadar横空出世(上)
< 返回列表时间: 2019-09-11来源:OSCHINA
本文作者:AIOps智能运维
作者简介
运小贝 百度高级研发工程师
负责百度内网质量监测平台( 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智能运维与您同行!
原文链接地址: https://developer.baidu.com/topic/show/290301
热门排行