百度网络质量监控实战：猎鹰一战成名（下）

我们在上一篇文章《百度网络监控实战：猎鹰一战成名》（上）中，初步介绍了百度外网质量监控的典型场景与需求，本篇文章将从外网监控的实现原理及系统架构两个方面系统详细介绍百度外网质量监控平台猎鹰。

一 外网监控实现原理

通过上一篇文章的需求调研，我们可以知道，业务线运维工程师希望外网监控平台能够真实反映用户到百度 IDC（Internet Data Center，互联网数据中心，又称机房）间的网络质量，并能够及时快速地发现机房侧故障、骨干网故障以及单省份故障，这里面有几个关键问题：

1 监控数据反映的是网络质量

对于业务线运维工程师来说，他们关注的是外网质量，因此，需要通过一种探测手段来实时反映网络质量。而探测协议有很多种，比如 ICMP、TCP、HTTP，那么哪种协议更适合呢？我们选择了 TCP 和 HTTP 来作为探测协议，原因有以下两点：

首先，网络设备在转发请求时，是根据请求的源 IP、源端口、目的 IP、目的端口、网络协议这五个信息决定请求的 Next Hop 所经过的链路或者设备。TCP 和 HTTP 协议有请求端口，而 ICMP 协议只有源 IP、目的 IP 以及网络协议这三个信息。那么对于一个监测点和一个被监测目标来说，由于 TCP 和 HTTP 探测请求的源端口可以不断的变化，因此 TCP 和 HTTP 探测方式能够比 ICMP 探测方式够覆盖更多的链路。

其次，用户访问百度服务的请求大多数是基于 TCP 和 HTTP 方式的，因此，TCP 和 HTTP 方式更接近于用户的访问方式。

在确定了探测方式之后，我们需要有探测指标来衡量网络质量的好坏，为了更加真实反映用户到百度服务之间的网络质量，我们将网络连接是否建立成功、连接建立的时延作为衡量网络质量的指标。对于 HTTP 探测方式，我们不关心 HTTP Code，只要连接建立成功，即使 HTTP Code 为 500，我们也认为网络正常。

2 监控数据反映用户到百度 IDC 的网络访问质量

为了能够真实反映用户到百度 IDC 间的网络质量，需要从用户侧向百度的的 VIP（Virtual Internet Address，百度多台服务器形成的一个虚机地址）发起探测。因此，我们在全国三大运营商各个省份部署了若干监测点，用于执行具体的探测任务。

3 能够及时快速地发现网络故障

为了尽可能快地发现网络故障，我们设计了基于数据驱动的网络故障检测模型。已有的故障检测模型大多是固定周期检测模式，比如检测周期是 1min，那么检测模型每两次相邻的检测需要间隔 1min，这种模式比较适用于流水数据、PV 数据的检测。但是对于网络异常检测的场景，实际上每两次相邻的检测并不一定需要间隔 1min，看下面这个例子：

假如 Tn 周期的检测时间点是 10:00:00，按照固定周期检测模式，Tn+1 周期的检测时间点则是 10:01:00，而实际很有可能在 10:00:35 的时候就已经收集够了相对充足的探测样本，足够判断出当前是否存在网络异常，那么在 10:00:35 就可以进行故障检测了，这样能够将故障发现时间提前 25 秒。

因此，在我们的基于数据驱动的网络故障检测模型中，我们对固定周期检测模式进行了改进，加入了探测样本数判断，如果提前收集到了足够的探测样本，则提前进行故障检测，尽可能地加快故障发现速度。

4 能够准确区分网络故障类型

当出现网络故障时，业务线运维工程师需要知道网络故障的类型，以便于采取对应的止损策略进行止损。我们针对机房侧故障、骨干网故障、单省份故障的表现特点分别设计了三种故障发现策略。

图 1 外网监控原理示意图

如上所述，我们通过在每个省份部署若干采集点，这些采集点周期性地向百度机房的 VIP 发起探测请求（HTTP 请求和 TCP 请求），并将探测结果进行上报，然后对探测结果进行故障判定，得到实时的网络质量和状态（如图 1 所示）。

二 系统架构

猎鹰整体系统架构如图 2 所示，主要包括采集服务、任务分发、数据分析与告警、元数据管理、存储以及可视化展示等六部分。

图 2 猎鹰整体架构图

1 元数据管理

元数据管理是整个系统最基础的一部分，它负责不同的实体映射关系维护，主要包括 VIP→机房归属关系、机房→VIP 的映射列表以及 VIP→域名归属关系。

在上一小节中提到，猎鹰部署在各个省份的采集点需要周期性地向百度机房的 VIP 发起探测请求，服务端接收到探测结果之后，需要把每个 VIP 的探测样本在 VIP 所属的机房维度进行汇聚计算，得到机房粒度的探测质量数据。因此，我们必须要维护 VIP→机房归属关系以及机房→VIP 的映射列表。

另外，在检测出故障后，我们需要判断出受损的业务线，因此需要维护 VIP→域名归属关系，比如检测出广东机房出现故障，我们根据机房→VIP 的映射列表得到所有受到影响的 VIP，然后再根据 VIP→域名归属关系分析出受影响的域名，从而得到受损的业务线列表。

2 任务分发

任务分发负责将采集任务分发到采集点，这里的采集任务主要指 VIP 探测列表，采集任务会指定探测目标（即 VIP）、探测协议（HTTP or TCP）、探测周期、超时阈值等。

3 采集服务

采集服务在采集点上运行，负责执行具体的采集任务。采集任务包括 HTTP 探测任务和 TCP 探测任务两种，在执行完探测之后，会将探测结果上报给上层的数据分析与告警服务，用于后续的数据处理与实时分析。探测结果包括两个指标：失败率和连接时延。

4 数据分析与告警

数据分析与告警是整个系统最核心的部分，包括数据收集、故障判定以及影响分析与告警。

数据收集用于接收采集服务上报的探测结果，并对探测结果进行一些清洗、去噪以及汇聚计算。

故障判定用于对清洗汇聚后的探测结果进行故障判定，通过三种故障发现策略来判断当前是否存在某种网络故障。

影响分析与告警用于进行故障通告和报警，当故障判定判断存在网络故障时，会通过元数据信息分析出受到此次故障影响的业务线，然后给这些业务的运维工程师发送报警。

5 存储

存储包括三部分：指标时序数据存储、异常事件存储以及元数据存储。指标时序数据存储主要存储实时的探测指标（失败率和连接时延），异常事件存储主要存储网络故障事件，元数据存储主要存储基础的数据归属映射关系。其中指标时序数据存储和异常事件存储使用的是百度通用的数据存储平台，元数据为内存存储。

6 可视化

可视化视图部分的展现非常重要，这个是对用户最直接的呈现。猎鹰的可视化视图主要包括三部分：全局网络视图、业务线网络视图、机房视图。

全局网络视图用来展现实时的全局网络状况，图 3 展示的是全局网络视图，包括故障公告、机房全局概览和产品线概览。故障公告展示的是最近一段内的网络故障通告。机房全局概览展示的是全百度所有机房的网络状况，如果有异常，会进行飘红显示。产品线概览展示的是接入猎鹰的所有产品线的网络状况，如果该产品线受到网络故障影响，则会飘红显示。

图 3 全局网络视图（示意图）

业务线网络视图展示的是各个业务线的域名以及 VIP 的网络质量视图，各业务线运维工程师可以很直观地观察到自己所负责的域名和 VIP 的网络访问质量。图 4 展示的是百度搜索产品线的域名网络质量视图，主要包括两部分：

图 4 业务线网络视图

1 域名网络连通性质量趋势图

展示的是某一段时间内全国所有省份访问某个域名的连通性情况，按运营商维度分别展示。

2 域名分省网络连通性视图

以地图的形态分运营商展示域名在每个省份的网络连通性质量，地图的每个省份的颜色会随着网络质量的好坏而变化，并且如果网络质量持续异常，地图上的省份会有红圈闪动。每个省份鼠标悬浮停留会展示该省份的网络连通性质量，包括探测异常率和响应时间两个指标。

机房视图展示的是全国各个省份到全百度各个机房的详细外网质量数据。这个视图包括两部分：

1 机房网络连通性趋势图

展示某个时间段内全国所有省份到某个机房的网络连通性状况。

2 可视化机房-省份连通性视图

机房-省份连通性视图以地图的形态细致地展现了每个省份到每个机房的外网访问质量，地图的每个省份的颜色会随着网络质量的好坏而变化。同时，地图上的省份可以和趋势图联动，点击地图的某个省份，右边趋势图展示的内容会变成选中的省份到该机房出的网络连通性数据。

图 5 机房视图

总结

猎鹰已经多次帮助发现重大网络故障，及时挽回了数千万可能的 PV Loss，在业务线日常运维工作中发挥着越来越重要的作用。接下来我们会继续秉承着“科技改变世界、技术改变生活”的理念将猎鹰打造成更加智能化的网络监控平台，让网络问题无处遁形。

作者介绍：

运小海，百度高级研发工程师，从事网络监控、可用性建设相关工作，负责百度外网监控平台猎鹰、百度内网监控平台 NetRadar 等系统的研发和优化工作。在网络采集、网络异常检测、系统可用性方面有广泛的实践经验。

本文转载自公众号 AIOps 智能运维（ID：AI_Ops）。

原文链接：

https://mp.weixin.qq.com/s/kaUWo7n0JbJdj2C0PgnROw