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

简介:

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

项目的需求是收集的客户系统一个月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%的所有告警,这些告警和该告警有时间上先后的关系,也就是这些告警统计上总是在该告警之后出现。

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


本文作者:刘建平

来源:51CTO

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
|
存储 前端开发 安全
前端开发
前端开发
319 3
|
机器学习/深度学习 人工智能 机器人
计算机视觉技术介绍
【10月更文挑战第14天】 计算机视觉技术介绍
|
11月前
|
存储 人工智能 调度
直播回放 | 高性能智算集群设计思考与实践
本次分享的主题是高性能智算集群设计思考与实践,由阿里云灵骏智算集群产品解决方案负责人丛培岩分享。 1. AGI对基础设施的挑战 2. 高性能智算集群的设计实践 3. 思考与展望
294 1
|
编解码 供应链 搜索推荐
虚拟现实与教育:沉浸式学习的潜力
【10月更文挑战第2天】虚拟现实(VR)技术正在革新教育领域,通过沉浸式体验提升学习效果和兴趣。本文探讨了VR在教育中的应用潜力,特别是在历史、地理、自然科学和语言教育中的案例。虽然面临设备成本和技术支持等挑战,但随着技术进步和成本降低,VR有望成为教育的重要工具,带来更丰富的学习体验。
|
算法 开发工具 git
使用 fuzzywuzzy 模块计算两个字符串之间的相似度
使用 fuzzywuzzy 模块计算两个字符串之间的相似度
240 1
|
JavaScript 前端开发 Go
一文彻底掌握Go语言运算符优先级秘密
一文彻底掌握Go语言运算符优先级秘密
407 0
|
机器学习/深度学习 编解码
mmseg配置解析 contract_dilation=True
`contract_dilation=True` 是 ResNetV1c 中的一种设置,用于解决多层膨胀卷积中的“栅格效应”。通过调整膨胀率,使卷积核在不同阶段更密集地覆盖输入特征图,避免信息丢失,提升特征提取质量,尤其在语义分割任务中效果显著。
268 0
|
关系型数据库 MySQL OLAP
PolarDB +AnalyticDB Zero-ETL :免费同步数据到ADB,享受数据流通新体验
Zero-ETL是阿里云瑶池数据库提供的服务,旨在简化传统ETL流程的复杂性和成本,提高数据实时性。降低数据同步成本,允许用户快速在AnalyticDB中对PolarDB数据进行分析,降低了30%的数据接入成本,提升了60%的建仓效率。 Zero-ETL特性包括免费的PolarDB MySQL联邦分析和PolarDB-X元数据自动同步,提供一体化的事务处理和数据分析,并能整合多个数据源。用户只需简单配置即可实现数据同步和实时分析。
|
弹性计算 运维 安全
阿里云轻量应用服务器:一款高效、稳定、安全的云计算服务
阿里云服务器ECS和轻量应用服务器有什么区别?轻量和ECS优缺点对比,云服务器ECS是明星级云产品,适合企业专业级的使用场景,轻量应用服务器是在ECS的基础上推出的轻量级云服务器,适合个人开发者单机应用访问量不高的网站博客、云端学习测试环境等,阿里云服务器网从从使用场景、适用人群、计费方式、系统镜像、网络带宽、运维管理等多方面来详细说下二者区别及如何选择
669 1
|
中间件 Go
Go语言中的中间件设计与实现
【5月更文挑战第4天】Go语言中的中间件在HTTP请求处理中扮演重要角色,提供了一种插入逻辑层的方式,便于实现日志、认证和限流等功能,而不增加核心代码复杂性。中间件遵循`http.Handler`接口,通过函数组合实现。常见问题包括错误处理(确保中间件能正确处理并传递错误)和请求上下文管理(使用`context.Context`共享数据以避免并发问题)。通过理解中间件机制和最佳实践,可以构建更健壮的Web应用。
350 0