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

奇技指南

_

用户在访问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. 数据的存储主要分为了四类，如下所示。

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

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

4. Mysql存储加白数据（vip加白）。

5. 元数据存储，内存存储（机房-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技术公众号

技术干货|一手资讯|精彩活动