用户工具

站点工具


service:techmag:201906_035:08

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

后一修订版
前一修订版
service:techmag:201906_035:08 [2019/08/14 08:53]
- 创建自 wiki:newitem 的表单
service:techmag:201906_035:08 [2019/09/11 09:30] (当前版本)
-
行 1: 行 1:
 ====== 基于机器学习的日志异常检测实践 ====== ====== 基于机器学习的日志异常检测实践 ======
-简要介绍条目 +文选自[[service:​techmag:​201906_035:​start|《交易技术前沿》总第三十五期文章(2019年6月)]] 
-{{tag>}}+{{tag>机器学习}} 
 +<WRAP centeralign>​ 
 +晏强 杨超 吴浩 孙伟 / 光大证券信息技术总部\\ 
 +</​WRAP>​
  
-<WRAP center round important 60%> +===== 1、引言 ===== 
-是一个面模板,编写面前请务必阅读[[wiki:newbie:start|编写须知]]。+  证券行业对信息系统的实时性、连续性有极高的要求,根据《证券期货业信息安全事件报告与调查处理办法》,将信息安全事件分为特别重大事件、重大事件、较大事件、一般事件四类,故障的恢复时间直接关系到事件的定级。证监会从2015年开始每年组织证券期货业网络安全联合应急演练,以提高全市场网络安全应急处置能力。从近几年的演练过程上看,各家券商基本上都建立了较为完善的自动化应急切换流程来节省切换时间,一旦原因定位清楚,切换时间可控,而整个过程耗时最长的通常问题的定位。\\ 
 +  监控系统是问题定位的重要依赖工具,般可以监控到问题的现象以及一些关键性能指标。对于问题的定位,单的指标通常来说帮助不大,例如CPU利用率可以反应当前服务器的负载情况,但是负载升高的原因仍然需要具体去排查,排查的过程主要是依赖于专家经验。对于复杂问题甚至需要多位不同领域的技术专家一起去排查定位。随着大数据、云计算以及分布式架构的不断成熟,使得通过大数据和机器学习的智能运维分析帮助运维人员定位问题变成了可能。\\ 
 +  目前智能运维领域在故障排查环节通过KPI的相关性、时序聚类等方法进行,如通过对某个应用从业务数据、应用数据、核心数据库数据、系统数据、网络数据、ITSM流程数据的关联分析来进行故障的快速定位,结合过往的实际运维经验,我们发现许多故障发生的原因往往会隐藏在日志里,系统KPI指标结合日志分析进行完整的数据分析和检测能覆盖到应用相关联的各个维度,帮助运维人员实现运维故障的根因定位。\\ 
 +  系统运行过程中产生了海量的日志(包括系统日志,应用日志,网络日志,设备日志等)。即使同一个日志也有多种模式,运维人员很难掌握各类日志格式进而开发出相应的解析规则,通常只对核心的日志进行解析。针对日志量大、格式繁多的日志,通过机器学习进行日志异常检测尤其是无监督实时检测与快速的故障定位就显得尤为重要,这不仅是对传统运维方法的改进和补充,也可以使证券行业的IT运维模式更加全、智能和主动。\\ 
 +===== 2、设计思路 ===== 
 +  光大证券基于现状分析提出了基于机器学习的智能日志异常检测的方法,通过大数据平台和算法的结合实现无监督实时检测与快速的故障定位。\\ 
 +==== 2.1 传统日志处理方法 ==== 
 +  证券行业使用的系统较多,由于系统来自于不同的开发商,各个系统的开发中对日志的定义很难做到一致性、标准性,这样就导致了日志的多种多样。传统方式主要通过基于关键字和解析规则两种方式对日志进行监控和问题监测,但是两种方法分别存在不足。\\ 
 +=== 2.1.1 基于关键字匹配对日志进行监控 === 
 +  基于关键字匹配存在日志中不一定有关键字就异常,例如ORACLE RAC在启动过程中会有一些预期的Error等字段,但是正常行为;\\ 
 +  针对不同类型的日志,很难标注出所有的关键字,事实上甚至有些程序日志中根本不会有类似的关键字。\\ 
 +=== 2.1.2 基于配置解析规则 === 
 +  基于配置解析规则,实现日志的字段的监控。如正则表达式的方法虽然比基于关键字有了一些改进,当然是仍然存在以下几个缺点:\\ 
 +  ■规则复杂:一些日志往往有大量的格式,解析工作非常复杂,需要大量花费大量时间进行调试;\\ 
 +  ■性能差:需要实时对来自的多个系统的海量日志进行多个规则解析,性能较差。\\ 
 +==== 2.2 日志智能异常检测方法 ==== 
 +  为了改进传统的日志处理方法,我们基于系统日志的故障诊断或者主动检测引入机器学习方法,自动提取日志模版并且通过分析从历史故障中发现相关的模式(故障关联关系或者故障征兆)从而实现异常检测。\\ 
 +  对于日志模版而言,支持增量式学习是一个重要也是必备的能力。因为运维人员经常部署软件或者硬件升级以引入新的特征,或者解决以往版本的程序错误,这些更新可以产生新的子类型的系统日志消息,而这些新的系统日志不能映射到任何现有的模板上。因此需要从这些的系统日志消息中提取新的模板,并且加入到模板集合中。\\ 
 +  针对海量日志行智能异常检测的设计思路如下:\\ 
 +=== 2.2.1 日志分词 === 
 +  分词会把一条完整的日志分割成若干词语构成的序列。和一般的自然语言分词不同,文本日志中有大量的关键词,是一般文本中不会大量出现的。而这些关键词可能会提供和系统非常相关的信息,而且其特征非常明显。例如,时间信息、IP地址、文件路径、内存地址等等。因此日志分词的过程中要对这些进行特别处理。\\ 
 +=== 2.2.2 模板提取 === 
 +  基于海量日志自动提取模板、变量。通过自然语言处理技术,分析大量日志中的共性和常见模式,提取日志模板。提取日志模板可以有效将大量文本日志结构化,去除大量冗余数据。日志模板和变量提取是日志智能异常检测的关键技术,这里我们主要采用了FT-TREE算法来进行提取,后会做详细介绍。\\ 
 +=== 2.2.3 异常检测 === 
 +  根据模板计数、变量取值来进行日志异常检测。根据之提取的日志模板,可以在线流式地对日志进行处理和数据抽取。例如,抽取每种类型的日志每分钟日志量,抽取特定类型的变量分布情况,如文件路径长度、文件传输速度等等。之后,采用单指标异常检测方法,和变量相关度分布度量,即可实时地对日志中抽取的数据进行异常检测。\\ 
 +=== 2.2.4 数据集成 === 
 +  异常检测后的数据需要与数据展示平台进行整合和集成产生实际价值。其中,智能运维数据分析平台从数据采集源或者第三方提供的数据库中获取数据作为数据来源,经过分类提取、整合和入库后,分别通过流式在线和批式两种方法消费。产生的分析结果和告警信息分别通过数据接口和告警信息队列提供给前端和第三方平台。用户和三方平台也可以通过前端或接口对数据获取、算法分析和告警推送流程进行配置。参考的平台数据流与系统如图1:\\ 
 +{{ :service:techmag:​201906_035:​1.zujian.png ​|}} 
 +<WRAP centeralign>​ 
 +图1
 </​WRAP>​ </​WRAP>​
-===== 二级标题 ​ ===== 
-\\ 
-\\ 
-==== 三级标题 ==== 
-\\ 
-\\ 
-=== 四级标题 === 
-\\ 
-\\ 
-== 五级标题 == 
-\\ 
-\\ 
----- 
-===== 参考文档 ​ ===== 
-最后请列出所有参考的公开资料的URL。 
  
 +  其中,关键组件包括:\\
 +  ■数据队列:由采集平台主动写入数据或者由订阅系统从第三方系统中定时获取数据,以队列的方式供智能运维数据平台系统消费。\\
 +  ■数据库:备份获取的数据,生成并存储智能分析模型元数据,和分析结果的时序数据等。\\
 +  ■告警信息队列:流式计算产生的异常和告警信息均通过该消息队列由第三方订阅。\\
 +  ■RestAPI接口:既可以用于采集平台主动推送数据,也可以对接北向接口,由应用系统或其他三方系统获取分析数据并进行调整。\\
 +===== 3、核心算法技术 =====
 +==== 3.1 日志智能异常检测常见算法 ====
 +  通用的系统日志预处理的方法是从历史系统的日志中提取模板,然后,将日志消息映射到模板上,模版提取准确率以及支持增量学习是处理海量日志的考虑关键因素。\\
 +  日志的异常识别算法中,LogClass算法是基于有数据标签的场景(即哪些日志是正常的,哪些日志是异常的);而DeepLog是无监督的方法,不需要提前准备数据标签;日志的根因定位算法FOCUS,是基于系统日志快速分析是什么条件造成了响应时延增加;SyslogDigest是专门针对网络设备的syslog进行分析的算法,它可以从原始syslog产生有实际含义的、可按优先级排序的网络事件;FT-tree是一种通用的日志模版生成方法,在日志模版生成后可以应用到日志的分类和统计、异常检测等领域中,从而大幅度提高分析人员的效率。\\
 +  通过深入调研以上几种算法,结合光大证券的实际日志情况,我们选择FT-Tree作为日志模板提取和异常检测的算法基础结合KPI异常检测算法实现日志的智能异常检测。\\
 +==== 3.2 分词算法与FT-Tree通用日志模版提取算法 ====
 +  现有的分词算法可分为三大类:基于字符串匹配的分词方法、基于理解的分词方法和基于统计的分词方法。按照是否与词性标注过程相结合,又可以分为单纯分词方法和分词与标注相结合的一体化方法。\\
 +  由于海量日志的格式千变万化,不可能通标标注的方式进行分析,所以我们通过单纯分词的方法,结合FT-Tree进行模板和特征变量的提取。\\
 +  FT-tree是一种拓展的前缀树结构,用以表示系统日志消息模板,是清华的研究者根据频繁模式树(frequence pattern tree, FP-tree)转变而成,FT-tree准确率较高,并且支持增量学习,其基本思想是,系统日志消息中详细信息字段的子类型通常是频繁出现的单词的最长组合。因此,提取模板等价于从系统日志消息中识别出频繁出现单词的最长组合。\\
 +  基于FT-Tree算法建立的算法模型,天然支持增量学习,可以很好地处理流式日志,随着日志的增加,不断完善和更新模板集。在具备了日志模板后,便可以很容易地将各种不同的日志转为模板序列,对其进行频率统计、变量分布识别,从而进行异常检测。原理以及步骤如图2:\\
 +{{ :​service:​techmag:​201906_035:​2.buzhou.png |}}
 +<WRAP centeralign>​
 +图2
 +</​WRAP> ​
  
- +  基于FT-Tree的日志模板提取算法,主要流程分为三个部分:分词、模板提取和修正统计。\\ 
 +  分词部分对于通用文本分词和变量提取,我们制作了专用编译器来进行提取。这样只需要对日志进行一次遍历即可提取指定的所有类型变量和词语;我们也预留了接口,针对自定义性特别大的时间戳进行运维人员定制的提取,这部分采用正则表达式匹配的方式实现。两种方式结合整体提取效率能够达单核每秒处理上万条文本日志。\\ 
 +  核心模板提取算法采用的是FT-Tree,这种算法本质上是一种基于词频统计的词典树构造-检索算法。相对于绝大多数传统模板提取方法(例如常见的聚类方法),FT-Tree可以以线性时间完成更高精度的提取,在训练样本数据量较大(千万级别)时优势更加明显。\\ 
 +  最后我们采用了计算模板编辑距离的方式评估模板提取效果,并对非常相似的模板尝试聚合。\\ 
 +==== 3.3 KPI异常检测算法 ==== 
 +  日志模版和关键值完成提取后,我们采用KPI异常检测算法进行分析和检测,根据时间序列的特征,计算资源的分配以及数据的时间来合理选用不同的模型组合来训练并生成对应的模型,其中所采用的技术和算法包括:\\ 
 +  ■变分自编码器\\ 
 +  ■渐进梯度回归树\\ 
 +  ■差分指数滑动平均\\ 
 +  ■极值理论\\ 
 +  ■周期性中值检测\\ 
 +  数据积累到一定程度即可开始在实际环境中在线检测,在线检测使用已训练好的模型对应的关键特征生成算法来生成新的时间点的特征,并用已训练好的模型对新的时间点的异常程度打分,从而来判断异常。\\ 
 +===== 4、生产实践过程分享 ===== 
 +==== 4.1 异常检测过程描述 ==== 
 +  异常检测的过程可以简单的概括为:通过单指标异常检测发现问题,通过多指标聚类分析定位出模块和指标,通过日志分析检测具体分析问题。过程如图3。\\ 
 +{{ :​service:​techmag:​201906_035:​3.yichang.png |}} 
 +<WRAP centeralign>​ 
 +图3 
 +</​WRAP>​  
 + 
 +  生产实践中,在我们在建设的智能运维平台中,我们以应用为单位,采用不同的方法搜集了从业务到基础环境的六类相关数据分别是:业务数据(如交易笔数、资金等)、应用数据(如功能耗时、调用成功率)、核心数据库数据(读写、锁等待、TPS等)、系统数据(CPU、IO、硬件告警、性能等)、网络数据(流量,端口状态)、流程数据(工单、CMDB)。这些数据来自于不同的系统,通常来说对于业务数据和应用数据来自于APM监控工具或者日志解析;操作系统数据、核心数据库指标、网络数据来自于基础网络监控工具或者操作系统监控工具;流程数据和CMDB数据来自于ITSM服务平台。\\ 
 +  对于每一类数据我们根据运维经验抽取了出了关键指标,通过对历史数据的学习获取数据的关键特性比如周期性、偏移度、抖动度等,然后通过根据这些特性采取不同的线检测器对单个指标进行流式实时在线异常监控。\\ 
 +  异常监控后续的故障原因定位,我们的解决方式是从单KPI检测异常入手去发现问题,然后再去进行多指标异常定位,根据对多个指标异常度的判断、相似机器的聚类、最终根据给出KPI的排名定位到具体的模块或者设备。在定位到具体的模块和指标之后,接下来就是需要通过日志分析进行异常检测的原因分析。\\ 
 +==== 4.2日志异常检测过程 ==== 
 +  我们介绍的具体场景为:某日,O32应用管理员通过单指标异常告警应用响应时间异常,通过多指标定位到数据库syscpu与lock_waiting指标异常,最终结合日志智能检测分析找到了具体的原因。其中,单指标、多指标异常检测,不是我们本篇讨论的重点,我们就不做过多介绍,下面我们重点介绍日志异常检测的过程。\\ 
 +  涉及到的日志包括了应用系统在运行中产生的一系列日志,包括:接入程序产生的runlog、utodb.log,中间件ASAR 产生的trade.log、asfund.log以及ORACLE RAC的alert日志等。\\ 
 +  日志的异常检测主要包括通过离线学习,从日志中提取出模版和变量,在根据提取的模式对现有日志进行异常检测。\\ 
 +=== 4.2.1系统日志智能模板 === 
 +  该应用系统的日志量较大,每类日志每月累积数据量能多达十几亿条。因此在实际生产的过程中,建立日志模型为了确保计算效率,避免干扰数据带来的误差,会对大量的数据进行一定的取样工作,方式有两种:\\ 
 +  ■一种是直接对近几日的日志建立模型,因为近几日在较少的数据量下可以较为全面地表现所有日志类型;\\ 
 +  ■另一类是对日志进行降采样,这样能够更好地反映日志的周期特性。本文的处理选择了后面一种模式。\\ 
 +  通过一个月的采样日志数据进行建模,提取应用日志runlog-utodb的日志模板。根据采样的100万条日志一共识别出了几十个个模板。日志量占比排名前十的模板,其模板格式和以6小时为采样间隔对其进行计数统计的结果。详见图4。\\ 
 +{{ :​service:​techmag:​201906_035:​4..png |}} 
 +<WRAP centeralign>​ 
 +图4 
 +</​WRAP>​ 
 + 
 +=== 4.2.2 系统日志特征变量提取 === 
 +  在runlog日志模板提取的基础上,对每类模板日志数量统计随时间出现频率,以及每个位置的变量其类型、各种取值分布情况等。图5显示了最常见的一类日志的统计信息:这类日志占据了99.9%的日志数量;其数量随时间分布具备了一定的周期性;关键的订单处理方式变量(3号变量),其几种处理方式的占比情况可参见左图下。这些统计信息将会进一步帮助我们将来进行异常定位。\\ 
 +{{ :​service:​techmag:​201906_035:​5..png |}} 
 +<WRAP centeralign>​ 
 +图5 
 +</​WRAP>​ 
 + 
 +=== 4.2.3 系统日志异常检测 === 
 +  模版与特征变量提取完成后就进入异常检测与分析阶段。在实际应用中,通过重点对应用运行日志runlog-utodb提取的反应系统运行情况的关键指标进行智能异常检测,发现日志产生异常行为的时间点;在该时间点对匹配后的日志数据进行下钻分析,可以获得更多的异常时段详情,进而详细了解本次异常和哪种类型的日志相关,其数量变化和内容变化的严重程度。\\ 
 +  ■第一步、进行日志和性能指标的关联分析,日志的抽取功能支持多种类型指标的抽取,包括,日志总体数量指标、各类日志数量指标,某类日志指定变量的均值/​最大值/​最小值指标等等。通过对之前runlog日志的最频繁出现日志类型进行计数统计抽取,我们发现其指标的异常分布和其他业务指标和监控指标(例如图6的数据库CPU使用率)是有关联关系的。\\ 
 +  ■第二步、业务指标和机器指标进行关联的异常检测,可以得出系统发生显著异常的时间点。之后,根据产生数量异常的日志类型和样例,可以对异常情况进行初步分析判断。\\ 
 +  在本场景中,在几个点9点多以及14点多都发现了应用指标响应时间以及数据库syscpu发现异常,在这个时间点,我们发现对应的日志模版和变量的数量也发生明显的增多,如下图6所示:\\ 
 +{{ :​service:​techmag:​201906_035:​6..png |}} 
 +<WRAP centeralign>​ 
 +图6 
 +</​WRAP>​ 
 +  ■第三步、异常时段变量分布对比。单从日志的数量上,无法准确发现异常,以及理解释异常的真实原因。通过对比正常时段与异常时段的变量分布情况,可以帮助我们定位到问题发生的原因。例如下图7中,系统将平日训练时产生的日志各类变量分布(正常时间段对比),和异常时间段产生的同类型日志变量分布(异常时间段对比)自动作出对比。\\ 
 +{{ :​service:​techmag:​201906_035:​7..png |}} 
 +<WRAP centeralign>​ 
 +图7 
 +</​WRAP>​ 
 +  日志中变量的对比统计数据如下表:\\ 
 +|变量|变量名|正常时段|异常时段| 
 +|4号变量|组播序号|平均分布|集中在某几个点| 
 +|6号变量|返回值|返回值为0的占比92%|返回值为0的占比下降到21%;返回值为700的占比飙升到78%| 
 +|7号变量|返回信息|返回信息为空的占比95%|返回信息为空占比下降到20%;返回信息为“异步落库失败”占比飙升到10%| 
 +  ■第四步、结合日志摘要,最终问题确认。通过以上智能分析给出的结果,我们发现4号、6号、7号变量存在明显异常,结合日志摘要(如图8),就可以确认异常日志为“[撤单处理]:​[应答][明细]记录序号[0],​组播序号[xxxxx],​委托序号[xxxx],​返回值[700],​返回信息[撤单异步落库失败,原委托状态为正报.]”\\ 
 +{{ :​service:​techmag:​201906_035:​9.tu8.png |}} 
 +<WRAP centeralign>​ 
 +图8 
 +</​WRAP>​ 
 +  经过应用系统管理员和应用厂商确认后,“返回值[700],返回信息[撤单异步落库失败,原委托状态为正报.]”问题为近期新发现的bug,不影响业务,厂商已经发布了相关补丁包,后续我们计划升级,至此一个问题快速定位的流程结束。\\ 
 +===== 5、结语 ===== 
 +  本篇介绍了光大证券在智能运维领域利用机器学习的方法对日志智能异常检测的方法和过程,相较传统的基于关键字和解析规则的处理,通过无监督算法的引入,采用日志分词、模版提取和异常检测的方法无疑可以降低运维人员工作量的情况下大幅提升快速定位问题的能力。\\  
 +  证券行业的业务系统是一个复杂的大型异构系统,针对不同的应用,智能运维工作的场景和需求都不相同,单一的算法和方法较难适用于各个场景。本文也介绍了通过单指标实时监测,多指标故障分析,日志智能检测故障定位的智能异常定位的运维方法,完整的智能运维场景应用对于提升运维效率和水平有着更高的价值。\\ ​              
 +===== 参考文献 ===== 
 +牛新庄, 双轮驱动,打造数字化智能银行,​ 中国金融电脑,​ 2018.9\\ 
 +裴丹,​基于AIOps的无人运维,​ 高效运维 2018\\ 
 +张戎, 腾讯运维的 AI 实践,​高效运维 2018\\ 
 +曾军, 周国富. 基于机器学习的多语言文本抽取系统实现[J]. 计算机应用与软件,​ 2017, 34(4): 87-92.\\ 
 +孙大为, 张广艳, 郑纬民. 大数据流式计算:​ 关键技术及系统实例[J]. 软件学报,​ 2014, 25(4).\\ 
 +张中峰, 李秋丹. 社区问答系统研究综述[J]. 计算机科学,​ 2010, 37(11): 19-23.\\ 
 +Akshansh Jain MachineX: Understanding FP-Tree Construction Jun. 01, 18\\ 
 +[[https://​dzone.com/​articles/​machinex-understanding-fp-tree-construction|MachineX:​ Understanding FP-Tree Construction]]\\ 
 +Seth Paskin:A Roadmap to AIOps. June 18, 2018\\ 
 +[[https://​www.bmc.com/​blogs/​a-roadmap-to-aiops|A Roadmap to AIOps]]\\
  
阅读
service/techmag/201906_035/08.1565772820.txt.gz · 最后更改: 2019/08/14 08:53 由 -