百度网络监控实战：NetRadar 横空出世（下）

本系列文章的上篇：《百度网络监控实战：NetRadar横空出世（上）》对百度内网质量监测做了初步介绍。作为该系列文章的下篇，本文将从核心功能、设计框架、异常检测策略以及可视化视图四个方面进一步介绍百度内网质量监测平台—NetRadar。

核心功能

在上一篇文章中我们提到，为了回答关于内网质量的问题，监测平台需要能够执行按需监测以及持续监测两种类型的测量任务。此外，为了实现主动告警以及故障可视化，还要求监测平台能够对测量结果进行分析，并明确告知是否有网络故障。因此，NetRadar 平台包含两大核心功能：监测任务的可定制与持续执行以及测量结果的智能分析。

监测任务要求 NetRadar 架构具备两个特性：

01 全量部署 Agent

持续监测和按需监测要求每一台服务器都必须能够参与测量。

02Controller-Agent 架构

Controller 负责统一协调控制 Agent 执行各种监测任务。

那么，NetRadar 的系统架构具体是怎样设计的呢？

NetRadar 系统结构图

NetRadar 整体系统结构如图 1 所示，主要包括 Controller 端、Agent 端 、汇聚端及业务端四个部分。其中 Controller 和 Agent 负责执行监测任务并获取测量数据，汇聚端负责数据的汇总和分析，业务端则展示分析结果并向其它平台提供数据。

图 1 NetRadar 系统结构图

1.Controller 端

Controller 是测量子系统的核心，负责持续测量任务和按需测量任务的管理和调度。

持续任务

Controller 根据任务配置和网络拓扑结构生成每个 Agent 的探测目标，即每个 Agent 的 ping 列表。Agent 采用 pull 模式定期获取该列表的内容。

按需任务

用户提交任务后，Controller 根据网络拓扑信息将任务拆解为每个 Agent 需要执行的测量任务，并采用 push 模式将任务内容推送给对应的 Agent。

2.Agent 端

Agent 根据 Controller 下发的测量任务执行测量操作，并把测量结果发送给汇聚服务器。测量操作包括 ICMP ping，TCP ping，traceroute 等。

另外，由于 Agent 部署在线上服务器，需要避免干扰线上业务的正常执行，所以 Agent 需要不断检查自己消耗的系统资源，当资源使用超标时停止执行新的探测任务。我们对 CPU、内存、磁盘等资源消耗进行限制。

3.汇聚端

汇聚端的功能主要有以下两点:

测量结果，形成指标数据

由于 QoS 队列、协议以及统计方式的不同，每对服务器之间的网络测量可以生成 27 种网络性能指标（如图 2 所示）。另一方面，我们还需要将服务器之间的测量数据按照网络拓扑结构汇聚为反映 ToR 之间、机房内集群之间、机房之间的网络质量指标。最终，整个系统会产生达百万级别的质量指标。

图 2 27 种监控指标

为了降低资源消耗，并提高可用性，采用“Adaptor-Aggregator 多个实例、两层汇聚”的方式进行汇聚，如图 3 所示。

图 3 Adaptor-Aggregator 两层汇聚设计图

Agent 优先（随机）选择本地域内的一个 Adaptor 来发送数据，并在本地域以及其他地域各选择一个 Adaptor 作为备选，当主 Adaptor 失效时依次选择备选 Adaptor。另外，Adaptor 收到数据后，采用一致性哈希的方式根据数据的“汇聚 key”进行汇聚，并将汇聚结果发送给 Aggregator，由 Aggregator 进行最终的汇聚。

这样做的好处是可以将汇聚计算的压力分散在 Adaptor 和 Aggregator 模块，同时降低了汇聚数据到 Aggregator 的资源消耗。

生成异常事件

在完成指标数据汇聚后，汇聚端直接进行异常检测，并判断是否有故障发生。如果确定网络故障发生，则向相关人员和系统发送警报。

4.业务端

业务端将汇聚端生成的指标数据和监测到的故障时间分别保存在 TSDB 和 EventDB 中，用于可视化展示或提供给其他平台使用。TSDB 和 EventDB 是百度运维内部成熟的数据存储平台。其中，TSDB 主要用于存储时间序列数据，适合存储指标数据；EventDB 主要用于存储事件类型数据，适合存储故障事件数据。

另外，业务端还通过分析不同业务线所部署服务在网络拓扑中的位置，得到业务线网络拓扑，从而实现按业务线定制化展示以及进行网络故障通告的功能。

异常检测策略

测量子系统所生成网络质量指标多达百万级别，不可能通过人工监视的方式发现网络故障，因此需要能够自动运行的异常检测策略。指标的数量巨大，表现也有很大的差异，这就要求异常检测策略是通用的、低开销的、高鲁棒性的。

NetRadar 平台的异常检测思想如下：首先确定“正常的网络性能指标值”，当观测到的指标值偏离“正常值”较大时视为异常。基于此，我们采用 Percentile of Absolute Deviation around the percentile (PAD)方法进行异常检测，该方法使用指标的历史数据确定指标的基准值和偏离程度基准值，然后利用这两个值判断观测值是否异常。

图 4 给出了异常检测策略示意图，其中上图表示某延迟指标时间序列，下图表示该时间序列的分布以及采用 PAD 异常检测策略确定的一般异常、严重异常分界值。

图 4 异常检测策略示意图

可视化视图

为了展示测量数据和异常检测结果，我们设计了可视化展示方案，如图 5 所示。

图 5 NetRadar 可视化展示示意图

NetRadar 首页由事件流图、趋势图和机房连通性矩阵三部分组成；

事件流图

事件流图展示发生异常的区域或机房的信息，包括名称、异常起止时间以及异常程度（一般、严重），如果全网都没有异常，则显示“无事件”，同时，严重异常的事件会在首页顶部进行通告；

趋势图

趋势图可以查看不同时刻的异常指标数，包括全部、区域以及机房三个级别；

机房连通性矩阵

机房连通性矩阵视图可以展示不同时刻不同机房间的网络质量。

以上展示内容可以根据业务线信息进行定制化展示。

作者介绍：

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

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

原文链接：

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

本篇将从核心功能、设计框架、异常检测策略以及可视化视图等方面对 NetRadar 平台进行系统介绍。