用户在访问 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
评论