日志和告警数据挖掘经验谈——利用日志相似度进行聚类,利用时间进行关联分析

摘自:http://www.36dsj.com/archives/75208

最近参与了了一个日志和告警的数据挖掘项目,里面用到的一些思路在这里和大家做一个分享。

项目的需求是收集的客户系统一个月300G左右的的日志和告警数据做一个整理,主要是归类(Grouping)和关联(Correlation),从而得到告警和日志的一些统计关系,这些统计结果可以给一线支持人员参考。

得到的数据主要分为两部分,一部分是告警的历史数据,这部分数据很少,只有50M左右,剩下的全部都是日志数据。日志数据大概有50多种不同类型,对应系统中不同的模块。每种类型的文件每天产生一个日志文件,所以总数大概是1500个左右的日志文件。文件大概都是这样的:A_2016-04-15.log, B_2016-04-15.log, …, A_2016-05-14.log, B_2016-05-14.log。每个文件在10M-1G之间不等。

1. 日志的模式挖掘

通过查看日志,发现所有的log每一行基本都是类似这样的Pattern:

YYYY-MM-DD hh:mm:ss [模块名] [具体日志]

每类日志的模块名都是一样的,基本可以忽略。有价值的就是时间戳和具体日志。

而且可以发现,很多日志只是极少部分动态内容不同,在代码中属于同一个位置的输出,这些数据后面我们会分为一类数据。比如:

2016-04-26 00:30:38.795 55637   ResourceManager Free ram (MB): 244736

2016-04-26 00:34:38.795 55637   ResourceManager Free ram (MB): 244748

有某些类型日志每个时段都有出现,咨询后得知基本没有任何分析价值,这些日志后面我们会加入黑名单,不加分析。

2. 日志的归类

由于每类日志都有30个文件,每个文件基本都有100万行,我们的第一步工作就是去除上面提到的无用日志。去掉无用日志后,我们要分析的日志大概减少了30%。

接着我们要做的就是每一行的日志进行归类(Grouping)。这里有很多的方法可以选择,比如K-means,但是我们这么多的日志,很难去定义一个合适的K。经过一番尝试后我们放弃了K-means。但是K-means的思想还是可以用的。最后我们使用的是启发式的方法来归类。

首先定下的基本思路是: 对于每一类文件,我们分别做归类,最后再一起和告警文件做关联(Crrelation)。我们作了不同类别文件的日志肯定不在一类的假定。

对于每一类文件的每一行日志,我们我们通过对具体日志的字符串的相似度进行归类,算法如下:

1)初始化将最终类别数组设置为空,类别数组的每一行的格式是 [index] [类别里第一次出现的具体日志内容] [该类日志出现的所有时间形成的数组]

2)初始化字符串相似度阈值,相似度超过阈值的字符串即为一类。项目里面我们相似度阈值取80%。

3)初始化归类的时间间隔,在一个时间间隔内的相似日志仅仅记录一次时间。也就是说如果某类日志已经有这段时间的记录,再次在这段时间出现的类似日志将会被忽略。取的过大,后面关联时精确度降低,取的过小,后面关联时计算量会很大。项目里我们取10分钟作为日志间隔。也就是一天划分成了24*6个时间间隔。

4)对于某一种类别, 对于每一行的具体日志我们去和该类别的最终类别数组的每一行的具体日志做相似度比较:

a) 如果和最终类别里的某行具体日志的字符串的相似度超过了阈值,则这两个字符串即归为一类,仅仅把这个要分析的具体日志的时间点存入该类别,停止该行日志的分析。

b) 如果和最终类别里的任何一行具体日志的字符串的相似度都低于阈值。则我们发现了一个新的类别。在最终类别里加入一行记录。并把该日志的时间间隔对应的点作为该类别的时间数组的第一条时间记录。

5) 对于所有其他的类别,分别执行上面的第4步。得到所有类别的最终类别数组。最终我们的50多个类别数组一共只剩下100多M,每个数组平均有100多种类别。

这个算法产生的类别数组中每一行是这样的内容:

1  ResourceManager Free ram (MB): 244736   [[2016-04-26 00:30],[2016-04-26 10:40], …]

上面的算法中,我们用到了字符串相似度算法。这里我们用到是python的字符串下相似度算法库:python-Levenshtein。计算相似度我们用了python-Levenshtein库的ratio函数,即莱文斯坦比。如果大家对python-Levenshtein的字符串相似度计算有兴趣,可以参考python-Levenshtein的官方文档:https://pypi.python.org/pypi/python-Levenshtein/0.12.0#id1

3. 日志和告警的关联

现在我们有了50多种日志的类别数据,每个类别也有在时间分布上的数据,同时,回到告警,每个告警也有在时间分布上的数据。现在我们可以在时间维度上做关联算法

我们的日志类别数组和告警在时间维度一共有30*24*6=4320个点。我们的目标是找到和每个告警在时间维度上关联度比较高的一组日志。这里我们采用的是基于余弦相似度的算法(???)。我们选择了所有的和告警在时间维度上相似度超过80%的日志类别。这些类别作为最终的统计结果作为我们输出的一部分。

4. 告警和告警的关联

这部分工作主要是研究告警和告警之间的统计关系。主要是基于统计的在时间维度上的父子关系。

由于告警数据较少,我们将时间间隔精确到1分钟。对于每一种告警,我们检查在该告警和其他告警在时间维度上的关系。我们检查3种情况。

第一种情况是在相同时间间隔出现的兄弟告警和该告警的统计关系,我们选择在时间维度上和该告警相似度超过80%的所有告警,这些告警和该告警有时间上同步的关系,也就是这些告警统计上总是和该告警同时出现。

第二种情况是在该告警出现前一分钟内的所有父亲告警和该告警的关系,我们选择在时间维度上和该告警相似度超过80%的所有告警,这些告警和该告警有时间上先后的关系,也就是这些告警统计上总是在该告警之前出现。

第三种情况是在该告警出现后一分钟内的所有儿子告警和该告警的关系,我们选择在时间维度上和该告警相似度超过80%的所有告警,这些告警和该告警有时间上先后的关系,也就是这些告警统计上总是在该告警之后出现。

以上就是对日志和告警数据挖掘的项目经验总结,希望对大家有所启发。

作者:刘建平Pinard(十年码农,对数学统计学,数据挖掘,机器学习,大数据平台,大数据平台应用开发,大数据可视化感兴趣。博客:刘建平Pinard

时间: 2024-08-09 10:33:13

日志和告警数据挖掘经验谈——利用日志相似度进行聚类,利用时间进行关联分析的相关文章

日志和告警数据挖掘经验谈

最近参与了了一个日志和告警的数据挖掘项目,里面用到的一些思路在这里和大家做一个分享. 项目的需求是收集的客户系统一个月300G左右的的日志和告警数据做一个整理,主要是归类(Grouping)和关联(Correlation),从而得到告警和日志的一些统计关系,这些统计结果可以给一线支持人员参考. 得到的数据主要分为两部分,一部分是告警的历史数据,这部分数据很少,只有50M左右,剩下的全部都是日志数据.日志数据大概有50多种不同类型,对应系统中不同的模块.每种类型的文件每天产生一个日志文件,所以总数

分析VTL以及利用日志备份还原数据库到指定时间

本文原整理于2012-09 一备份链 USEMASTER; GO CREATEDATABASElogtest 运行如下语句 USElogtest go DBCCloginfo 图1-1 运行如下语句可以看到产生很多VTL USElogtest go SELECTTOP 10000 *INTOt1 FROMAdventureWorks.Sales.SalesOrderHeader DBCCloginfo 图1-2 运行如下语句可以看到日志被截断,标记为可重用状态(status=0) USElogt

MsSQL利用日志备份恢复到某一时间点

在做update或delete操作时忘带where条件或where条件精度不够,执行之后导致数据丢失或更新错误等严重后果,如果你的数据库已有相应的完整备份,并且不能备份日志(truncate log on checkpoint选项为1)可以利用事务日志的备份来进行数据恢复. 恢复数据具体步骤如下: 1,首先要做的事就是进行一次日志备份(如果为了不让日志文件变大而置trunc. log on chkpt.选项为1那就没法子了)     backup log dbName to disk='D:\N

日志归档与数据挖掘

日志归档与数据挖掘 http://netkiller.github.io/journal/log.html Mr. Neo Chen (陈景峰), netkiller, BG7NYT 中国广东省深圳市龙华新区民治街道溪山美地 518131 +86 13113668890 +86 755 29812080 <[email protected]> 版权 ? 2013, 2014 Netkiller. All rights reserved. 版权声明 转载请与作者联系,转载时请务必标明文章原始出处

SQL Server 2014 日志传送部署(7):日志传送故障转移和删除日志传送

13.4 故障转移 13.4.1 故障定位 在前几节明确的提及到,日志传送由三个基本的作业组成:备份作业.复制作业和还原作业.通过上一节日志传送监控功能来定位哪一个作业出了问题: 如果备份作业出了问题,检查主服务器状态. 如果还原作业出了问题,检查辅助服务器状态:或者辅助数据库处于STANDBY模式时用户正在使用辅助数据库. 如果复制作业出了问题,检查除了辅助服务器状态外,还需要检查网络状态. 13.4.2 故障转移 日志传送的故障转移除了考虑切换技术操作以外,更需要考虑主服务器和辅助服务器之间

解决Linux下Tomcat日志目录下的catalina.log日志文件过大的问题

本文摘自:(http://blog.csdn.net/stevencn76/article/details/6246162) 分类: Java技术专区2011-03-13 12:25 5017人阅读 评论(1) 收藏 举报 tomcatlinux工具任务web 由于Tomcat在默认情况下会将没有经过配置的web应用所产生的日志输出已经其本身的日志内容都输出到这个文件中,那么随着时间的推移,这个文件的尺寸将会越来越大,当需要检查日志内容时间会导致文件难以打开,而且同时tomcat依旧在不断的向文

SQL Server中的事务日志管理(7/9):处理日志过度增长

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的.你只要确保每个数据库都有正确的备份.当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时.这系列文章会告诉你每个DBA应该知道的具体细节. 这篇文章会列出导致事务日志过度增长的常见的问题和错误管理形式,包括: 在完整恢复模式里,没有进行日志备份 进行索引维护 长时间运行或未提交的事务阻止事务日志里空间重用 当然,如果增长没检查,日志文件会扩展直到吞没所有可用磁盘空间或日志文件的最大大小,在这个时候你

shell在大文件日志中按照时间段快速搜索日志

问题描述: 在大流量线上服务中,日志系统会产生数量庞大的日志,动辄就是几十G.在如此之大的文件中快速搜索日志是运维人员经常遇见的问题.我们经常遇见的问题是查询一段时间内的某些条日志.比如,今天有一个访问失败了,大约是在上午9点,把这条日志找出来,然后查找失败原因. 常见处理方式及缺点: 1.如果文件比较小,100m以内使用grep.awk或者sed进行逐条匹配比较方便,但是文件非常大时,其查找效率是非常低的,运行时间长达几十分钟甚至上小时. 2.使用hadoop大数据处理,查询速度快,效率高.但

使用log4j2打印Log,log4j不能打印日志信息,log4j2不能打印日志信息,log4j和logj2,idea控制台信息乱码(文末)

说来惭愧,今天就写了个"hello world",了解了一下log4j的日志. 本来是想在控制台打印个log信息,也是遇到坎坷重重,开始也没去了解log4j就来使用,log4j配置文件开始用的log4j.properties,结果控制台一直打印ERROR StatusLogger No log4j2 configuration file found.也就是Log4j2配置文件没找到的意思. 我就把log4j.properties文件名改成log4j2.properties,结果不报错了