28

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

 4 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzU4ODgyMDI0Mg%3D%3D&%3Bmid=2247487205&%3Bidx=1&%3Bsn=2531263ba1a223a4c68ee3bde0ce53a1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

女主宣言

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

PS:丰富的一线技术、多元化的表现形式,尽在“ 3 60云计算 ”,点关注哦!

b6Bj6zY.jpg!web

1

背景介绍

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

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

vIfaEni.png!web

系统特点

  • 实时性检测(分钟级)。

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

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

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

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

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

2

系统框架

源主机的选择-CDN机器

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

raa6Bjy.png!web

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

系统原理

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

BraMRjN.png!web

系统架构图

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

RZB3aqI.jpg!web

任务下发

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

优点:

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

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

agent数据采集

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

uQFjyuV.png!web

存储

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

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

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

3、Mysql存储加白数据(vip加白)。

4、元数据存储,内存存储(机房-vip、省份-vip等映射关系等)。

3

报警策略

故障策略

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

  1. vip故障

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

  2. 机房故障

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

  3. 运营商故障

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

数据分析与告警

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

    2euQ3ye.png!web

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

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

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

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

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

3

可视化

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

7neAfma.jpg!web

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

Fb2iY3E.jpg!web

vip加白。

JfqqmyF.png!web

报警内容。

ZvUb63f.png!web

4

系统规划

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

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

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

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

  • 接入stackstrom自动切换vip。

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

360云计算

由360云平台团队打造的技术分享公众号,内容涉及 数据库、大数据、微服务、容器、AIOps、IoT 等众多技术领域,通过夯实的技术积累和丰富的一线实战经验,为你带来最有料的技术分享

eY7fInQ.png!web


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK