这个分享最重要的包含智能监控的技术实现,以及大规模日志监测数据的自动化接入两部分。我先介绍一下智能监控部分,下一期分享中我的两位同事将给大家着重介绍日志分析处理的计算。智能监控现在其他一些公司也有在做,希望能够通过这次分享能够给大家带来一些新的启发,也欢迎各位能够提出问题和建议,互相切磋交流经验。马小鹏
分享内容的提纲如下:Goldeneye智能监控的业务背景、技术思想、技术实现细节、难点和今后的优化方向。
马小鹏,阿里妈妈全景业务监控平台技术负责人。2013 起在阿里从事大规模系统日志分析及应用的研发,曾经主导了直通车广告主报表平台和实时报表存储选型。在加入阿里之前,曾负责网易电商 App 数据统计平台的研发。
Goldeneye作为阿里妈妈业务监控平台,主要在业务日志、数据的实时统计分析基础上做监控报警以及辅助定位。阿里集团内部也有很多优秀的监控平台,它们在开放性上做的很好,接入成本也不高,但是监控阈值也是开放给用户自己设定。这种情况下,对于业务监控人工维护阈值就很复杂,需要有丰富的经验来拍定阈值,需要人工持续的维护不同监控项的监控阈值。所以,在业务加快速度进行发展的前提下,传统的静态阈值监控很容易出现了误报、漏报的问题,而且人工维护成本高,监控视野局限。Goldeneye就是在这种基础上,我们试着从大数据应用的角度,去解决业务监控中的问题,由此诞生的。
(1)体量大:Goldeneye现在接入的业务线%业务,每天处理的日志量在100T以上,业务监控需要对各业务线的流量分层级实时监控,核心数据以1分钟为周期,一般监测数据以5分钟或1小时为周期,监控目标非常多,按人工维护这些监控的阈值、启停、生效实效等几乎是达不到的。
(2)变化多:业务监控的监测数据大都是业务指标,不同于系统运维指标,比如RT/QPS/TPS等一般是较为稳定的,业务指标具有周期性变化的特点,比如工作日和节假日的区别、业务经营销售的策略调整的影响等,在这种情况下人工设定的静态报警阈值准确性就很难保障了。
(3)迭代快:随着阿里妈妈资源整合和业务的加快速度进行发展,监控目标也经常发生明显的变化,比如流量监控资源位的调整、效果监控的产品类型划分等,曾经出现过新流量上线. 技术背景:
通常的业务监控系统或平台,都是由采集、数据处理、检测、报警等模块组成的,Goldeneye也是如此,不过它的技术架构上用了阿里内部的一些技术中间件,比如采集个人会使用TimeTunnel(它有agent在各台日志服务器上拉日志到Topic,并且负责将离线日志放到ODPS上),这部分我不再介绍了。
数据处理个人会使用的jstorm和ODPS MR job分别对日志进行实时、离线批处理,最重要的包含日志解析、校验、时间周期归一化、聚合、写存储(HBase)等操作,这部分下一期分享中我的同事会详细的介绍。今天的分享大多分布在在阈值预测、监控检测、报警生成通知、辅助定位这四部分。
智能监控就是让系统在业务监控的某些环节上代替人工执行和判断的过程。人工维护监控目标和阈值是以经验为参考的,系统如何自动判断哪些目标需要监控、自动设定监控目标的阈值水位、不用人力维护,是基于对历史样本数据统计分析得出判断依据。
通过收集监测数据的样本,并使用智能检测算法模型,让程序自动对监控项指标的基准值、阈值做预测,在检测判断异常报警时使用规则组合和均值漂移算法,能精确地判断需要报警的异常点和变点。
给指标M1设置同比、环比波动幅度,比如同比波动20%、环比波动10%触发报警;
以上两种方式,是平常大家常用的监控方式,但是效果确不理想,这种静态阈值长久来看没有适应变化的能力,需要人工维护,而且报警准确性也依赖于同环比数据的稳定性。
我们能否让系统具备自动适应变化的能力,自动调整阈值水位?就如同手动挡的汽车换成自动挡一样,能够准确的通过速度自己调节档位。
当我们的监控系统具备预测动态阈值的能力后,监控项的维护是否也可以交给系统去做?
可能大家也曾遇到过类似的情况,旧的监控项已无数据了,新的监控目标却因为种种原因被漏掉,人工维护监控项需要及时同步上下线变更,但是当我们应该监控的目标有一千个、一万个甚至更多的时候,人力是无法一直跟进这些监控项的维护工作的,或者说这种工作比较单调容易被忽视。
我们能否将判断如何筛选监控项的规则交给系统,让它去按时进行检查哪些监控项已经实效,哪些监控项需要新增,哪些监控项的阈值需要调节。这种发现规则是稳定的,仅仅是依据发现规则得出的监控项内容在一直在变化而已。
当我们的监控系统具备预测动态阈值、自动发现并维护监控项的能力后,如何达到不漏报和不误报之间的平衡?
通常的做法是为了不被误报干扰至麻木,会把阈值调节得宽松些,但是这样的做法易产生漏报,尤其是下跌不太明显的情况。
Goldeneye采取的思路是对误报case欲擒故纵,在首先确保不漏报的基础上降低误报率。先监控产生疑似异常点,这一环节我们基于动态阈值去检测时相对严格一些(或者说这一环节不用考虑报警收敛的问题),然后对这些疑似异常点再做验证、过滤,最终生成报警通知,验证和过滤的依据是预先定义的规则,比如指标组合判断、报警收敛表达式等。
下面介绍技术实现的一些细节,分为监控系统的架构、动态阈值、变点检测、智能全景、辅助定位五个点。
Goldeneye监控系统的四个输入:实时监测数据、历史数据、预测策略、报警过滤规则。
(1)阈值参数:设置基于预测基准值的系数决定阈值上下限区间、分时段阈值预测系数、分报警灵敏度阈值预测系数;
(2)预测参数:样本数量、异常样本过滤的高斯函数水位或者过滤比例、基于均值漂移模型的样本分段选取置信度等。
关于报警过滤规则,主要是为了在充分捕捉疑似异常点的前提下,过滤不必要的报警。比如指标M1异常,但是组合规则是M1和M2同时异常才报警,这种就会过滤掉。再比如,按照报警收敛规则,一个监控项的第1次,第2次,第10次,第50次连续报警需要我们来关注,可设为收敛表达式为1,2,10,50,那么在报警通知生成时对于第3,4,,9,11,12,,49次报警可忽略,因为反复通知的意义不大,这个规则可以按需要达到自动收敛。也可以在同一监控项的多个实例同时发生异常报警的情况下,按规则合并成一条报警,这些规则可以按详细情况去实现,最终的目的是以最简洁的方式暴露最需要我们来关注的报警。
(这里补充一句,我们最近在考虑新的收敛方式,对第1条和最后1条报警,并且自动计算出累积gap,这样异常的起止和影响区域更明显)
监控使用控制图,对监测指标的时间序列可视化,让人类能清楚的看到指标的波动。基于控制图的监控,以往很多都是静态阈值方式,比如前面提到的静态水位线、同环比。动态阈值是为控制图的时间序列每个点,预估该点对应时刻这个指标的基准值、阈值上限、阈值下限,从而让程序能自动判断是否有异常。因为这种预估基于过去几个月甚至更多的历史样本作为参考,所以比同环比两个数据作为参照的准确度要高。动态阈值预测的理论基础是高斯分布和均值漂移模型。
(2)异常样本筛除:这样的一个过程主要使用高斯分布函数过滤掉函数值小于0.01,或者标准方差绝对值大于1的样本。
(3)样本截取:因为后来我们优化的版本,在(2)的基础上使用均值漂移模型对历史样本在时间序列上进行分段检验,如果有周期性变化、或者持续单调变化,则会反复迭代均值漂移模型寻找均值漂移点,然后截取离当前日期最近第一段(或者能够理解为最近一段时间最平稳的样本序列)。样本选取还有一个必须要格外注意的问题,节假日和工作日的样本要分开选取,预测工作日的阈值要选择工作日的样本,节假日亦然,也就是对预测样本从日期、周末、平稳性三个维度拆分选取。
(4)预测基准值:经过(2)和(3)的筛选、截取,剩下的样本绝大多数都是最理想的样本了,在此基础上,保持样本在日期上的顺序,按指数平滑法预测目标日期的基准值,得到基准值以后根据灵敏度或阈值系数,计算阈值上下限。
(补充说明:第四步预测基准值,有些人可能之前用过指数平滑法预测,跟第四步我们在样本权重加权时的做法很相近,但是他们预测的效果不理想,因为对样本整体没有充分的过滤选取最稳定的样本集合)
动态阈值用数据统计分析的办法解决了静态阈值的误报漏报问题,节省了人工维护的成本,某些特定的程度上降低了监控风险。不过在微量波动、持续阴跌的故障面前,动态阈值也有局限性,阈值区间收的太紧误报会增多,区间宽松就会漏报一些不太显著的故障。在review漏报case时,我们从控制图上发现这些微量波动肉眼可以观察到趋势,但是程序通过阈值区间击穿的判断方式很难控制,所以引入了均值漂移模型来寻找变点。所谓变点,就是持续微量下跌到一段时间,累积变化量到某些特定的程度后,使得变点前后监测指标在一段时间内的均值发生漂移。
《嵌入式系统模块设计》11-常见嵌入式硬件(其他硬件到结束)及系统级设计方法(开始到计算机设计)
三季度中国可穿戴市场同比增长7.5%,全球同比增长2.6%,创两年来当季最高出货纪录
由双通道智能化传感器信号处理器MAX1463构成的高精度压力测试系统的电路框图
由智能化传感器信号处理器MAX1460和硅压力传感器构成的压力测试系统电路
《嵌入式系统模块设计》10-常见嵌入式硬件(典型的ARM系统到Boot ROM的制作)