外网质量监控系统实践之路

用户在访问 360 服务器时，会经过运营商链路、各省的机房然后到达 vip，那么在这个链路中任何一个环节出现问题，都会导致用户无法正常上网。如何快速、准确的定位到这个链路中的哪个环节出现了故障？对于运维的人员来说是至关重要的。下来跟随作者一起来探讨下外网质量监控系统在 360 是如何实践的吧。

背景介绍

用户在访问 360 服务器时，会经过运营商链路、各省的机房然后到达 vip，那么在这个链路中任何一个环节出现问题，都会导致用户无法正常上网。如何快速、准确地定位到这个链路中的哪个环节出现了故障？对于运维的人员来说是至关重要的。

假如没有外网质量监控系统，那么我们是如何确定故障的呢。传统的方式是被动式的，当用户反映不能正常上网后，运维人员开始申请账号、登录主机、然后执行 ping、telnet 等命令来查看服务器是否可以正常访问，耗时又耗力，而且还不能准确的定位到具体的故障。比如，某个 vip 不能访问，可以是由于 vip 原因或是机房故障还可能是运营商的原因，而我们手动探测的链路太有限了。外网质量探测系统应运而生。

系统特点

• 实时性检测（分钟级）。

• 端到端持续检测（真实反映用户到 vip 的网络访问质量）。

• 全覆盖监测（覆盖全国三大运营商的各个省份）。

• 按需下发检测任务（简单灵活的接入方式）。

• 检测结果主动报警（准确快速地主动告警，确定故障类型及影响范围）。

• 支持不同视角的可视化展示（cdn 机器到 vip、运营商到 vip、机房到机房的平均延迟、丢包率、最大最小延迟等）。

系统框架

源主机的选择-CDN 机器

要进行外网探测，源主机的选择是我们要解决的第一个问题。那么我们有必要先看一下用户上网的流程是什么样的。如下图所示。

用户通过域名访问某个网址，三级域名系统给用户返回了 ip（vip 的地址）或者 cip（cdn 的 ip 地址），然后用户通过 ip 或者 cip 来访问后端服务器。用户的机器肯定是不能够作为源主机的。从剩下的机器中，我们看出，cdn 节点在这里起到了关键性的作用，我们将 cdn 节点作为源主机，添加故障判断逻辑后，可以准确的判断 vip 故障、机房故障及运营商故障，这也正是我们进行外网监控的目的所在（比如单个运营商所 ping 的所有 vip 中，有一半的 vip 丢包率都大于 50%，那么我们是不是可以认为这个运营商有问题了。所以 cdn 节点作为源节点非常合适）。

系统原理

利用三大运营商部署在各个省份的 cdn 机器来周期性的向 vip 发起 ping 操作。运行流程为：cdn 机器向 vip 发出 ping 包，将结果存储到时序数据库，然后故障判定模块从时序数据库中拿数据，进行分析之后，发出报警。我们的指标，主要是丢包率和平均时延。

系统架构图

整体架构主要分为三层。展示层、数据采集层和数据分析层。展示层：我们支持 grafana 以及自研的 web 系统展示，比如 watchman。数据采集层：我们借助了公司内部成熟的 wonder-agent 和大数据网关来进行数据收集。公司内部有 10 万台 wonder-agent，wonder-agent 在启动时，会判定自己的宿主机是否是我们想要的源，如果是，启动 ping 模块，并从网关那里拉取自己所 ping 的 vip 列表。由于 agent 的宿主机所处的运营商不同，我们会将不同运营商的 agent 划分到相应运营商的 lvs 下，这样就会避免 wonder-agent 上报数据超时的问题，也解决了断点问题。数据存储好之后，我们来看数据分析和报警层，数据分析模块，会从 influxdb-ha 来拉取时序数据，每分钟拉取一次，然后进行故障判断，生成报警。

任务下发

Center 网关生成每个 CDN 机器所 ping 的 vip 列表。通过对所有 vip 进行分片，保证同一个机房下的不同 cdn 服务器所 ping 的 vip 列表没有交集，并且同一机房下的 cdn 所 ping 的 vip 列表的并集为全部的 vip。然后，agent 主动从 center 网关拉取 vip 列表，同步周期为 1 小时。

优点：

• 避免了 ping 风暴，减小了 vip 的负载。

• 减小了 agent 采集数据的压力。

agent 数据采集

agent 通过执行 ping 功能来周期性的获取每个 vip 的存活状态，并上报给网关，其执行流程如下图所示。

存储

数据的存储主要分为了四类，如下所示。

1、Influxdb 时序数据库。存储实时的探测指标数据（平均延迟、最大最小延迟、成功率等）。

2、Mongo 存储故障数据（聚合）运营商故障、vip 故障、机房故障）。

3、Mysql 存储加白数据（vip 加白）。

4、元数据存储，内存存储（机房-vip、省份-vip 等映射关系等）。

报警策略

故障策略

故障的判断方式一共分为三种，如下所示。

1.vip 故障

1 个或者大于 1 个运营商一半以上的省份丢包率大于 50%报警（针对 lato 机房国内全部省份到 lato 都丢包 100%报警）。

2.机房故障

大于等于 2 个运营商、或者大于 10 个 vip 小于等于三分之一的 vip 丢包率大于 50%：怀疑机房故障大于等于 2 个运营商、或者大于等于二分之一的 vip 丢包率大于 50%；判断为机房故障。

3.运营商故障

单个运营商大于等于三分之一的省份、或者大于等于三分之一的 vip 丢包率大于 50%：怀疑（电信运营商）故障。单个运营商大于等于二分之一的省份、或者大于等于二分之一的 vip 丢包率大于 50%；判断为（电信运营商）故障。

数据分析与告警

1.平滑过滤掉毛刺数据。

其中，a1-a5 都是由 vip 组成的 vip 列表，通过求 a1-a5 的并集，将得到的结果（即去掉毛刺的数据）作为最终判断故障的元数据。

2.根据故障策略以及元数据对数据进行故障判定。

3.根据业务聚合，生成不同的故障报警内容。

4.提供业务名称或者部门 id 发送对应的报警内容。

5.不关注的报警，业务可以选择加白。

可视化

cdn 机器到目的 vip 的平均延迟、最大、最小延迟以及丢包率。

全国各省市到各个运营商机房的平均延迟。

vip 加白。

报警内容。

系统规划

在提供安全可靠报警的同时，未来努力的方向。

提供按需检测任务接口，主动下发，目前只支持被动获取（这样的话如果加 vip 列表，只有等到定时触发，不能很及时的进行探测）。

支持多种探测方式。包括 tcp ping、icmp ping 和 http ping。

添加异常检测机器学习算法（平均延迟更智能）。

接入 stackstrom 自动切换 vip。

对七层 URL 实现访问延迟和状态的监控。

本文转载自 360 云计算公众号。

原文链接：https://mp.weixin.qq.com/s/CIi9k2soHuLhwnkqnMtPdg