百度网络监控实战，多维度分析应用场景-InfoQ

2021腾讯数字生态大会直播预约通道开启！技术内容大爆发，开发者必看！了解详情 



 写点什么

干货概览

大家在收集数据的时候常常会往数据上附加一些标签，这些标签从不同的角度对数据加以描述，我们把这些角度称作维度，这些附加了维度信息的数据称作多维度数据。

在收集到数据后，我们往往只关注那些和预期不一样的数据，从多个维度检查这些异常数据集中在什么地方，我们把这种分析方法称作多维度分析。

在网络监控里，我们可以用多维度分析的方法定位网络故障。接下来，本文将以百度内网质量监测的场景为例，介绍多维度分析的实战经验。

内网质量监测需求

百度拥有数十万台服务器，分布在全国各地的几十个数据中心（机房）中，这些服务器通过内网连接起来对外提供服务，这个网络是一个多层级的分布式结构，主要层级有：地域、机房、集群、ToR(Top of Rack，机架)。

图 1 百度内部网络拓扑示意

大家看到的各个服务通常是模块化的设计，这些模块部署在不同机房的不同服务器上。一旦内网发生故障，模块间的通信受到影响，会导致服务体验下降或不可用。在工程师发现服务故障的时候，会从程序、数据、宿主机环境、网络环境等各个角度进行检查，评估故障的影响范围，从而选择合适的预案来降低损失。在这个过程中对网络环境的排查是必不可少的。

一个典型的场景是：服务 X 的工程师发现可用性下降，由于服务部署在机房 A、B，需要检查这两个机房的网络环境有没有问题，有问题的话影响了整个机房还是某个 ToR 下的几台机器。

如果仅机房 A 的网络异常，需要将原本引到机房 A 的流量调度到机房 B；
如果仅机房 A 内的 ToR1 网络异常，只需要在机房内进行流量调度，将原本引到 ToR1 下的流量调度到机房内其他 ToR 下；

可以看到，不同故障对应的预案是不同的。工程师需要了解网络是否存在故障、故障影响了哪些机房、集群、ToR，然后才能选择合适的预案去执行。

内网质量监测方案

1 内网质量数据

在《NetRadar横空出世》里我们已经介绍过，内网质量监测中使用了端到端的方式进行探测，通过在服务器之间发送探测请求来监测网络质量。

在探测机房 A 到机房 B 之间网络状态的时候，我们从机房 A、机房 B 分别选出 n 个服务器 $a_{1}, a_{2}, \dots a_{1}$ 、 $b_{1}, b_{2}, \dots b_{n}$ ，从机房 A 中的服务器 $a_{i}$ 向机房 B 中的服务器 $b_{i}$ 发送探测包，探测结果会有成功、失败两种。

图 2 机房 A 中的服务器对机房 B 中的服务器进行探测的结果

通过这样的探测我们得到了一系列网络质量数据，这些原始数据中每条数据对应一次探测，数据内容包括探测样本的来源、目标和结果，比如从服务器 a1 探测服务器 b1 的结果为成功。

2 内网故障判定

得到原始数据之后，我们需要给出网络有没有问题的判断。

需要判断的网络问题有地域故障、机房故障、集群故障、ToR 故障，一个直接的思路是逐个检查这些需要判断的区域，比如要判断一个机房有没有发生网络故障，可以统计机房下的探测样本的总数和成功数，检查成功探测样本是不是太少。

为了描述方便，这里不再展开《还记得概率课本中的二项分布吗？在我们的网络判障中发挥了大作用！》中介绍过的基于二项式分布的判障方法，简单记作成功率低于 90%为异常。

在判断机房 A 的网络有没有故障的时候，可以把源或目标服务器在机房 A 下的探测样本挑出来，统计总样本数和成功样本数，得到机房 A 的探测成功率为 70%，低于阈值，所以认为机房 A 的网络存在故障。

图 3 机房 A 故障时的探测结果

这样，我们针对每个关注的区域都进行一次检查，就可以知道这些区域的网络有没有故障。

3 误报问题

我们逐个区域检查有没有网络故障的时候，会存在一些误报问题。

这里给一个机房 A 的例子，机房 A 里有 8 个 ToR，其中 ToR1 的网络出现了中断。这个时候，发送到 ToR1 下服务器的探测包会失败，从 ToR1 下服务器发出的探测包也会失败，又因为 ToR1 下服务器占机房 A 下服务器的 1/8，所以机房 A 的探测成功率会小于 90%，故障判定算法将会判定机房 A 存在异常。这个判定结果的范围大于实际故障范围，对服务没有部署在 ToR1 下的工程师来说是一次误报。

图 4 机房 A 中 ToR1 故障时的探测结果

可以看到，在判断一个区域有没有故障的时候，只检测源或目标服务器在这个区域的成功、失败样本数是不够的，这些失败可能是受到了其他区域故障的影响，我们需要更全面地进行分析。

多维度分析

1 误报问题分析

可以看到，在前面两个误报的例子中，如果更全面地进行分析，不同故障的表现是有很大区别的。

在 ToR1 故障的时候，机房 A 里的其他 ToR 的表现是正常的，源或目标机器在机房 A 下的失败探测样本大多集中在 ToR1 下，很少一部分在其他 ToR 下。而在机房 A 故障的时候，这些失败探测样本均匀分散在各个 ToR 下。

图 5 ToR1 故障（左）与机房 A 故障（右）的差异

可以看到，发生不同 s 故障时，失败样本的聚集情况有明显区别，我们需要报告的是失败探测样本聚集的一个或多个区域，这些区域具有失败探测样本多、失败探测样本在各子区域均匀分布的特点。

2 内网监测数据的维度

在分析误报问题的过程中，我们需要不断地筛选源或目标在某个区域、某个子区域的样本。为了让筛选更方便，我们给每个样本附加了一组标签，标记这个探测样本反映了哪些区域的网络质量。

对于图 2 中服务器 a1 到服务器 b1 的探测样本，需要附加的标签是：

源服务器=a1
源 ToR=1
源集群=1
源机房=A
源地域=Y
目标地域=Z
目标机房=B
目标集群=4
目标 ToR=10
目标服务器=b1

这样，探测数据变成了一组多维度数据，那些需要报告的网络故障可以用这些维度来描述，每个故障对应一个维度组合。机房 A、B 间网络异常对应“源机房=A，目标机房=B”或“源机房=B，目标机房=A”异常，机房 A 网络异常对应“源机房=A”或“目标机房=A”异常。子区域的故障则对应了细分维度组合，机房 A 到 B 的网络是机房 A 出方向网络的子区域，“源机房=A，目标机房=B”是“源机房=A”的细分维度组合。

我们用贡献度描述一个维度组合中失败探测样本的多少，用一致性描述失败探测样本在各个细分维度组合分布的均匀程度。所以，那些贡献度和一致性都很高的维度组合中失败探测样本较多、失败样本在各个细分维度组合均匀分布，和故障区域的特点一致，这些维度组合应当对应了正确的网络故障区域。