摘要:从剩下的机器中,我们看出,cdn节点在这里起到了关键性的作用,我们将cdn节点作为源主机,添加故障判断逻辑后,可以准确的判断vip故障、机房故障及运营商故障,这也正是我们进行外网监控的目的所在(比如单个运营商所ping的所有vip中,有一半的vip丢包率都大于50%,那么我们是不是可以认为这个运营商有问题了。运行流程为:cdn机器向vip发出ping包,将结果存储到时序数据库,然后故障判定模块从时序数据库中拿数据,进行分析之后,发出报警。

女主宣言

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

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

1

背景介绍

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

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

系统特点

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

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

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

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

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

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

2

系统框架

源主机的选择-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等映射关系等)。

3

报警策略

故障策略

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

  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. 不关注的报警,业务可以选择加白。

3

可视化

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

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

vip加白。

报警内容。

4

系统规划

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

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

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

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

  • 接入stackstrom自动切换vip。

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

360云计算

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

相关文章