58智能监控系统的整体设计与多维实现

龚诚 2019-07-17 14:27:24

一、监控系统概述

 

58智能监控系统的目标是为集团旗下各业务线提供灵活易用的监控产品,通过覆盖网络层、服务器层、系统层、应用层、业务层的立体化监控体系,实现7*24无死角的实时监控,保障公司各产品的稳定运行。

 

除传统监控产品支持的数据采集、存储、告警、展示等功能外,58智能监控系统还支持了关键指标的智能预测和异常检测、告警合并、告警关联分析、故障自愈、故障预警、自动化添加监控、灵活的自定义监控等功能。

 

1、监控系统核心功能
 

 

网站可能出现各种访问异常,造成故障的因素多种多样,在这么多可能故障的情况下,保障网站的服务稳定性必须要依赖智能的监控系统。

 

我们先来看一下监控系统的核心功能:

 

  • 采集数据:采集需要监控的指标数据,例如:服务器的资源使用率,应用服务的服务状态等;

  • 设置告警策略:灵活配置的告警策略;

  • 发送告警:支持多种告警方式,且要求告警准确,数量较少;

  • 数据查看:多维度监控数据的查看。

 

我们希望监控系统成为线上服务的守护神,它是服务稳定性的重要保障。

 

  • 平时,监控系统是运维和研发、测试人员的眼睛,协助我们快速发现和排查故障;

  • 通过将运维数据进行量化和可视化,便于技术人员对网站进行优化;

  • 另外,我们还要求监控系统具有一定的智能,可以根据大量信息给出有价值的结论,例如:告警的关联分析、故障的根因分析、自动给出系统的优化建议等。

 

2、立体化的监控体系
 

 

根据大型网站的通用架构,我们构建了立体化的监控体系,如下图所示:

 

 

监控纵向覆盖了:

 

  • 网络层:网络设备宕机,资源使用率,流量,服务质量,专线等;

  • 服务器层:宕机,无法登陆,硬件故障等;

  • 系统层:资源使用率(CPU、内存、磁盘、网络等);

  • 应用层:端口存活,进程存活,接口状态,服务QPS等;

  • 业务层:PV、UV、订单量,成交额等业务指标。

 

横向覆盖了:

 

  • 用户端:重点页面关键指标(可用性,首屏时间,全部加载时间等),DNS劫持,链路劫持,页面出错,页面超时等;

  • 机房网络出口端:VIP连通性监控,页面监控,接口监控等;

  • 流量接入端:网站总网络流量、三端(APP端、M端、PC端)网络流量等;在Nginx上实时统计的域名维度、集群维度数据;

  • 业务集群端:单机监控(纵向:服务器层,系统层,应用层,业务层),集群监控(页面、接口监控,Nginx日志监控;核心指标包括:可用性,响应时间)。

 

3、监控业务模型
 

 

由于互联网公司的服务器数量非常多,往往都达到万台、甚至几十万台,提供同一个服务的节点(服务器或容器)的数量非常多,为了便于管理,我们使用了基于集群的监控模型。

 

我们将提供同样功能、部署同样服务、监控方法一致的一组服务节点称为一个集群,所有监控配置项(节点列表,监控模板,告警接收人)与集群关联。该监控管理模型如下图所示:

 

 

这种监控业务模型可以允许业务非常方便的更新各种监控配置项。例如:

 

  • 对服务进行扩容或将故障节点剔除时,只需要从节点列表中做变更即可,无需更改其他项;

  • 需要增加、修改或删除告警策略的时候,仅需关注策略的变更,无需关注其他信息;

  • 用户订阅或取消订阅告警的时候,仅仅影响告警组中的用户列表,与其他项无关。

 

系统整体根据集群关联的节点列表、监控模板中的策略、告警接收人列表去实时的下发到告警控制模块,对告警产生影响。

 

4、提供更好的用户体验
 

 

用户可以在PC版的监控系统使用监控系统的所有功能。为了方便用户的使用,我们的界面分为三个区域,分别是菜单、服务树和业务展示区。

 

菜单供用户选择要使用的功能,选择了服务树的某个节点就确定了关注的业务范围,前两者确定了业务展示区展现什么数据和功能。如下图所示:

 

 

为了方便在移动场景使用监控系统,还提供了微信版的监控系统。在微信告警中,可以方便看到告警详情,及告警相关的监控指标的数据视图,另外还可以对无需处理的告警做屏蔽告警操作,备注告警的处理进展,便于多个负责人同步消息等。

 

 

二、多维度监控方法

 

为了确保发现各维度的异常,我们使用了多维度的监控方法,包括如下层级:

 

  • 基础监控:服务器宕机、资源使用率、网络质量;

  • 服务监控:端口状态,进程状态;

  • 自定义监控:多种多样个性化监控指标;

  • 功能监控:页面监控、接口监控;

  • 可用性监控:集群维度、域名维度的可用性、响应时间等;

  • 业务指标智能监控:对反映业务运行情况的宏观数据做智能预测、异常检测。

 

下面分别介绍一下实现原理。

 

1、基础监控、服务监控、自定义监控
 

 

上述三种类型的监控数据都由部署在服务器上的监控agent进行采集,数据采集后做数据的存储和异常判断,进而做视图展示和异常告警。

 

数据采集示意图:

 

 

2、页面、接口监控
 

 

网站的首页,或者重要的列表页、详情页是对用户体验影响较大的页面;APP端为了展现数据需要调用接口获取数据,接口的可用性也是非常影响用户体验的。为了及时、准确的发现关键的页面、接口的功能是否正常,我们开发了该项功能。

 

为了及时发现网站用户能够感知到的异常,我们通过域名解析出来的VIP,从外网访问指定的页面或接口,并验证域名解析、建立连接、HTTP状态码、响应时间等指标。并对页面监控验证数据长度、是否包含指定关键词等指标;对接口监控验证业务状态返回码、接口中特定字段的数据长度等指标。

 

由于现在的服务一般都是按照集群进行部署,单个节点出现问题,Nginx会做重试,少量节点出现问题外部用户不会感知到异常。为了及时发现该类问题,我们根据用户配置的参数,按照服务器的维度进行探测,该种监控方式能够及时发现服务器级别的异常,从而进行故障的预警。

 

 

3、集群、域名可用性监控
 

 

网站的所有流量经过四层负载均衡设备、Nginx集群转发到后端业务集群。在Nginx集群上可以看到后端业务集群的运行状况,我们通过实时收集和传输Nginx日志,使用Storm集群实时计算集群维度和域名维度的各种状态码数量和比例、响应时间等指标,进而做数据展示和异常告警。并在集群维度也按照服务器统计了上述指标,可以发现个别服务器的异常,做到对集群故障的预警。

 

 

4、业务指标智能监控
 

 

一些宏观的业务指标往往能够更准确、有效的反映业务的运行状况。我们对这些关键的业务指标使用了机器学习相关的技术,对数据做了预测和异常检测。该部分将在本文中稍后的智能监控部分详细介绍。

 

5、多维度监控方法总结
 

 

综上所述,我们对各维度的监控方法归纳总结如下:

 

 

三、整体架构

 

我们以open-falcon为基础,打造了基础的监控系统,基本结构如下:

 

 

我们在基础监控系统的基础上做了大量的优化、升级(图中黄色部分),增加了大量与智能监控相关模块(图中红色部分)。

 

 

四、智能监控实践

 

1、智能监控总体规划
 

 

我们希望做到对监控业务的全流程覆盖,如下图所示:

 

 

  • 故障预警:平时做好系统优化,故障前可以发出故障预警;

  • 故障告警:能对周期性变化指标进行预测和异常检测,且有告警分级;

  • 告警合并:支持按照合适的维度对告警进行合并,展现概况信息;

  • 根因分析:智能对故障根因进行分析,给出最可能的原因,辅助人做决策;

  • 故障自愈:可以根据故障原因选择合适的故障自愈策略并执行,自动解决故障。

 

2、关键指标的智能预测和异常检测
 

 

一些宏观的业务指标往往能够更准确、有效的反映业务的运行状况,例如:机房网络流量,业务访问量,订单数,成交额等指标。我们对这些关键的业务指标使用了机器学习相关的技术,对数据做了预测和异常检测。如下是一个业务指标的数据视图:

 

 

  • 需求背景:整体规律性较强、短期小幅波动较多的关键指标,不适合使用静态阈值;

  • 适用场景:网络出口流量或业务的进出流量,集群和域名的访问量,宏观业务数据;

  • 需求:按天对流量的提前预测,对实时流量的异常检测;

  • 技术方案:使用回归模型按天预测流量变化趋势,使用分类模型对实时流量做异常检测。

 

3、如何使用机器学习的方法
 

 

使用机器学习的方法分为四大步骤:明确问题,处理数据,训练模型,使用模型。按照如下的方式与我们的业务结合起来:

 

 

4、流量预测及异常检测技术框架
 

 

在技术框架上分为离线部分和在线部分,如下图所示:

 

 

智能预测的效果如下图所示,可以看到预测数据与实际数据的吻合程度较高,预测的效果还是比较好的。

 

 

智能异常检测的效果如下图所示,基于数据异常程度将异常分为:普通异常、严重异常、陡变异常。

 

普通的异常一般是一些突发的数据毛刺,一般不重要。

 

 

如果实际流量持续偏离正常值,我们将其识别为严重异常,这是需要相关研发和运维人员关注的,可能会造成故障。

 

 

当数据出现突然下降时,一般出现了严重的事故。例如:机房出口的带宽被攻击流量打满,系统出现严重问题等。这种异常是需要运维和研发人员及时知晓、立即处理的。

 

 

我们在实现了异常检测的基础上,又对异常做了分级,并实现了告警分级,不同级别的异常使用不同的告警方式。例如:陡变异常使用语音的方式告警,严重异常使用短信、微信的方式告警。

 

该异常检测模型有较好的普适性:

 

  • 适用于不同数量级的数据;

  • 适用于不同变化规律的数据;

  • 适用于不同业务的数据。

 

5、智能告警合并
 

 

如果每个异常都发送一条告警,那么告警的数量将是非常多的,对人的干扰也是较大的,需要人对大量数据做处理才能得到有价值的信息。我们通过智能告警合并的方式解决了该问题。

 

  • 合并时间窗口:兼顾合并效果和告警时效性,合并时间窗口为1分钟;

  • 合并收益:避免海量告警轰炸,快速掌握故障情况,辅助决策故障根因;

  • 合并策略:相同用户(对同一个人的告警合并),相同状态(异常,升级,恢复等),相同告警方式(语音、短信、微信、邮件);

  • 合并维度:根据集群合并,根据IP合并,根据网段合并,根据异常种类合并(宕机、端口不通等),根据宿主机与虚拟机的关系合并。

 

我们采用了基于基尼值的自创告警合并算法:

 

 

算法的执行步骤简述:

 

  • 遍历全部备选维度,确认当前合并维度;

  • 基于合并维度划分数据集,继续选择合并维度;

  • 到达停止条件后停止。

 

告警合并树由根节点向下生成,如图所示:

 

 

6、智能告警合并效果
 

 

下图所示为告警合并算法上线前后告警数量的对比图:

 

 

在保证了很高的告警合并质量的前提下,告警数量减少76.65%。从下图中可以看到,系统根据合并的多条告警给出了合并后告警概况信息,该信息已经达到或超出人与人之间沟通传递的信息量,便于技术人员快速判断异常的影响面和影响程度。

 

 

7、智能告警关联分析
 

 

网站中大量服务的关联关系是非常复杂的,如果出现故障,很难在大量信息中快速、准确的判断故障点。为了解决该问题,我们试图用智能的方式做告警的关联分析。关联的告警事件之间有一定的相关性:

 

  • 异常事件的时间相关性:关联的异常在相邻的时间段内出现;

  • 异常事件之间的相关性:服务之间存在调用或依赖关系;

  • 异常事件与变更事件的相关性:变更操作导致服务出现异常事件。

 

举一个实际的例子,58和APP端流量在一个时间端内出现较大的增长,如下图所示:

 

 

相关的集群访问量也出现变化,如下图所示:

 

 

按照传统的方法,运维人员要排查总流量的变化是由于哪些业务和集群引起的,需要耗费大量的时间和精力,从大量的集群中去做数据的分析

 

我们使用皮尔逊相关系数的方法,对大量可能有关联的监控指标做相关度计算,从而快速的发现告警之间的关联。

 

在微信告警信息中,不但能看到告警的详情,还可以看到系统根据算法自动给出的根因分析,且能看到数据的变化趋势。点击根因分析可以看到图形化展示的告警关联关系,如下图所示:

 

 

8、传统监控与智能监控的差别
 

 

最后做一个总结,在各方面对比一下传统的监控和智能监控的差别:

 

 

五、总结

 

58智能监控系统建设经历了多个阶段:自动化、立体化、产品化、智能化。

 

自动化:保证监控系统基础监控添加的自动化,从CMDB系统自动同步集群名称、负责人信息、节点列表,自动关联基础的监控模板,保证了基础服务器监控的自动化。

 

立体化:指对监控覆盖的立体化,从横向和纵向两个维度保证了对网站的立体化监控。

 

产品化:随着监控系统的功能越来越丰富、越来越强大,使用门槛越来越高,为了让内部用户方便、有效的使用,我们做了大量提升用户体验的工作。

 

智能化:随着网站中服务器数量的增加和业务复杂程度的增长,依靠传统的方式已经不能有效的满足需求了,我们引入了人工智能相关的技术,与运维相关的业务相结合,逐渐朝着智能化的方向前进。

 

 

作者:龚诚

来源:58架构师(ID:gh_a23aa6d3e68d

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告