百度内网连接着数十万台服务器,承载着全公司业务的网络通信,其通信质量的重要性不言而喻。而百度内网的质量监测平台 NetRadar(网络雷达),通过对整个内网“服务器端到端”传输质量进行监测,实现了快速、准确地发现、通告、定位内网问题,为百度业务的正常通信提供了有力保障。
《百度网络监控实战:NetRadar 横空出世》系列文章将分上、下两篇介绍 NetRadar 平台,本文主要介绍内网质量监测的意义、相关需求以及百度原有的内网监测技术,而下篇将从核心功能、设计框架、异常检测策略以及可视化视图等方面对 NetRadar 平台进行系统介绍。
百度内网介绍
百度拥有数十万台服务器,分布于全国各地的几十个数据中心(又称 IDC、机房)。这些海量的服务器通过网络分层级互联,构成了统一的“资源池”,对外提供可靠、强大的存储、计算和通信服务。
在软件架构上,百度的大型服务一般都是模块化设计,一次服务需要上下游大量模块共同协作完成。为了提高并发服务能力和容灾能力,这些模块会分布式地部署在不同机房的不同服务器上。为保证服务的正常运行,内网必须保证各模块具有良好的“端到端”网络通信能力,一旦出现网络故障并影响了模块间的通信,往往会对服务造成影响,甚至导致服务整体不可用。
为了提供高可靠、高性能的端到端通信能力,网络结构在设计上预留了大量冗余,既有设备的冗余,也有线路的冗余。这样一来,两台服务器间的通信可以同时存在许多条不同的路径,能够在一定程度上抵御网络故障。尽管如此,实际环境中端到端的通信问题依然常见,其原因主要包括:路由收敛延迟、ToR 交换机单点故障、网络拥塞等等。另一方面,即便单个设备、网线、服务器发生故障的概率很低,乘上巨大的数量,故障必然是“常态”现象。
在这种“与故障为伴”的环境下,既然无法避免故障,就需要能够及时、准确地监测内网质量,这对于保证服务正常运行来说是至关重要的。
需求调研
在运维实践中,工程师对内网质量监测系统都有什么样的需求呢?我们对各业务线的运维工程师,以及来自网络组的同学进行了调研。为了更好地说明用户需求,图 1 给出了一个典型的运维场景:
图 1 内网问题相关的运维场景
当运维工程师发现服务关键指标异常后,如果怀疑是内网故障导致的,则需要通过回答如下一些问题进行排查:
1)“机房 A 到机房 B 的网络有问题吗?”
2)“服务器 a 到服务器 b 网络有问题吗?”
如果经过检查确认内网没有问题,就要继续排查其他可能的原因,诸如上线、操作、程序 bug 等原因,以帮助进行有效的止损和恢复决策。而如果确定是内网故障导致服务受损,那么网络工程师为了诊断和修复网络故障,会排查一系列的通信问题来帮助缩小故障范围,比如:“哪些服务器通信有问题?”,“哪条链路有问题?”等。为了回答这些问题,最直接有效地方式就是“进行服务器端到端检测”,比如:
排查“机房 A 到机房 B 网络有问题吗?”
可以测试: 机房 A 大部分机器到机房 B 大部分机器间的网络质量
排查“机房 A 内部网络有问题吗?”
可以测试: 机房 A 大部分机器互相访问的网络质量
排查“服务器 a 到服务器 b 网络有问题吗?”
只需测试: 服务器 a 访问服务器 b 的网络质量
排查“哪些服务器通信有问题?”
需要挨个 ping 或 ssh 疑似有问题的服务器
排查“在哪条链路上出的问题?”
需要执行 traceroute 命令查看路由细节
图 2 人工测量网络质量步骤
但是,人工执行上述测试任务费时又费力。如图 2 所示,为了进行一次端到端的网络质量检测,首先要确定“源-目的”服务器,然后获得服务器的登录权限,之后才能登录到机器上执行各种测试操作,最终分析数据得到测量结果。显然,这种人工测量的方式可扩展性很差,无法应对大规模测量的需求。因此,需要一个平台能够实时地、自动地执行测量任务,给出分析结果。
那么,这个平台需要满足什么要求呢? 通过对业务线运维工程师和网络工程师进行调研,整理的需求如下:
1)“端到端”的持续监测
由于百度业务线的程序或模块均部署在服务器上,其网络通信也都是从服务器发起和接收,所以服务器“端到端”的网络质量更能反应内网状况对业务通信的实际影响。所以从业务角度出发,平台应当能够对端到端网络质量进行持续监测。
2)全覆盖的监测
实际中,运维工程师通常知道业务部署在哪些机房,但不清楚具体哪些机器间有网络通信,所以会关注 “这些机房网络是否正常”这种全局性的问题。此外,网络工程师的责任是保证整个内网质量可靠,需要系统地监测整个内网性能,尽可能地发现和修复网络故障,减少隐患。
3)按需下发监测任务
实际工作中常常需要根据现场情况执行特定的监测任务,这导致需要进行额外的、有针对性的测量。所以,监测平台还需支持按需监测。
4)检测结果主动报警
由于网络工程师直接对内网质量负责,因此希望监测平台在测量”端到端”通信性能后,对相关数据进行分析,判断网络是否正常,并在检测到网络异常后及时发送报警,以保证各业务线服务正常。
5)针对产品业务的定制化展示
由于一个产品业务通常只部署在部分机房,依赖部分网络,所以运维工程师往往不关注非其负责的。因此,监测系统需要支持定制化展示,使运维工程师能迅速获取其需要关注的网络状态信息。
那么,百度现有的内网监测技术能否满足以上需求呢?
现有监测技术
其实,百度内部已经应用了一些内网质量监测技术,这些技术利用不同的测量手段获取内网质量数据,并加以分析,进而判断网络是否正常。表 1 给出了三种现有监测技术的相关信息。
表 1 现有监测技术原理及不足
上述几种技术在内网质量监测和运维中发挥了一定作用,但在使用过程中也发现了一些不足,不能很好满足上述需求。因此,基于以上技术的实战经验,我们开发了新平台 NetRadar(网络雷达)。与以上监测技术相比,NetRadar 具有以下优点:
覆盖广:探测 agent 在全网 linux 服务器完成部署,覆盖了百度全部内网机房;
多层级:7*24 小时持续监测整个内网的网络质量,包括机房间、机房内集群间、集群内 ToR 交换机间的网络质量;
指标全:评价网络质量的方式多样,区分 QOS 队列、协议、统计值,共计 27 种网络质量监控指标,每个探测周期会产生近百万的监控指标;
检测准:通过自适应异常检测算法对监控指标进行检测,并进一步生成机房、区域级别的网络事件;
除此之外,NetRadar 还支持按需探测,并提供全内网“端到端”探测接口以及故障事件接口,以帮助工程师快速诊断网络问题。
作者介绍:
运小贝,百度高级研发工程师,负责百度内网质量监测平台(NetRadar)的业务端设计及开发工作。在系统和网络监控、时序指标异常检测、智能客服机器人等方向有广泛实践经验。
本文转载自公众号 AIOps 智能运维(ID:AI_Ops)。
原文链接:
https://mp.weixin.qq.com/s/p-LssHYxjBYhcm89OqPQZQ
评论