1.业务需求分析
1.背景
我司产品业务逻辑迭代深,系统依赖服务广、组件众多。因而,在系统出现故障时(bug触发、依赖服务超时等),错误日志的量级会急剧增加,错误日志内容会存在相互掩埋、影响的问题,开发人员面对爆发式的错误一时难以理清逻辑,无法第一时间解决核心问题。为此,我们需要构建辅助开发人员查错的工具。
SRM日志具有info、debug、error三种级别,我们先关注error级别的日志。若在报警流出现时,通过处理程序,将报警聚类,整理出一段时间内的报警摘要,那么运维人员就可以在摘要信息的辅助下,先对当前故障有一个大致方向的判断,再结合技术知识和业务知识即可定位故障的根本原因。
根据以上考虑,我们需要做以下工作:
- 选定聚类算法,理清算法的基本原理,总结出针对error报警日志聚类的可以实施的方案;
- 选用一段时间流内error日志(生产环境),对算法、处理流程进行验证,总结不足与优化、进步方案。
2.技术选型
我们会什么,做过什么,可能做到什么水平
1.所选用的方法基于经验和调研可能性
分词基于jieba或者nlk,停用词库是英文词库+redis缓存自定义停用词库的模式,文本聚类方法是余弦相似度算法,将以总分形式展开叙述
2.聚类流程详述
我们的先手目标是减少告警,也就是将短时间内相同/相似的告警聚类为一种以减少告警数目。
如何判定这一段时间内,连续出现的多条告警属于一个问题反复告警呢?通过日志的句子,分析句子,对句子进行聚类的方法就是机器学习文本分析聚类的范畴。
涉及到文本聚类,通常我们的思路是将文本切分成多个词汇,通过去掉一些无用的词汇、计算频次等方法确定关键词,然后转换为矩阵进行相似度计算,返回的结果是俩句子相似度值=>俩告警是不是一类。
3.探究
行业老大Splunk以及其他专业的公司和产品日志易、ELK、sumologic、prelert(ES收购)、oracle、vmware、阿里云日志服务系列。
其中,阿里的一眼看尽上亿日志-日志服务(SLS)智能聚类(LogReduce)效果比较好;
据日志易产品总监饶琛琳的分析文章日志分析的模式发现功能实现(4)可管中窥豹——阿里云LogReduce使用的是频繁模式挖掘(frequent pattern mining),然而这点因机器学习领域基础过于薄弱,为了做出东西,也未能去做,之后若有机会可以修改这一部分方法。
效果如下:
日志服务(SLS)用户手册
智能文本聚类-syslog分析