文本智能聚类——千万日志一览无余

【导语】对于海量文本型数据比如日志，如何从中提取日志模式以便更快地从文本中获取关键信息。本文先简单介绍了行业竞品的相关产品形态，然后重点介绍了一种基于机器学习的日志智能聚类解决方案——基于图结构的聚类方法。

目录

• 1. 价值收益
  • 1.1. 背景
  • 1.2. 目标
    • 1.2.1. 直接目标
    • 1.2.2. 间接目标
• 2. 产品形态
  • 2.1. 学术科研
  • 2.2. 行业竞品日志服务
• 3. 技术框架——基于图结构的聚类方法
  • 3.1. 流程框图
    • 3.1.1. 日志结构化
    • 3.1.2. 构建分词库
    • 3.1.3. 日志向量化
    • 3.1.4. 确定日志相似关系
    • 3.1.5. 构建特征库
  • 3.2. 聚类应用
  • 3.3. 补充
    • 3.3.1. 优点
    • 3.3.2. 缺点
    • 3.3.3. 向量空间余弦相似度
• 4. 总结

1. 价值收益

1.1 背景

Paas和Iaas平台上有很多很复杂的系统，每个云系统里面有很多不同的组件，每个组件之间有各自的日志输出。随着系统和业务的高速发展，各个系统每天产生大量的日志，有可能出现比如系统有潜在异常，但被淹没在海量日志中；新版本上线，系统行为有变化，却无法感知。同时，对于不同用户或开发者自定义打的日志，其格式并不一定相同，且随着时间的变化日志格式愈发多样。

以上问题归根到底，是信息太多太杂不能良好归类，同时记录信息的日志，往往格式多样难以统一规范，这对于AIOps排障是一个是否头疼的问题。如果能够将日志采集并进行聚类模式学习，通过AI算法把海量日志划分为少数的几种模式，这样原来几千万行的日志被归类为几十条，这样就能大大加快日志查看和故障排查的效率。

1.2 目标

1.2.1 直接目标

智能聚类将相似度高的日志聚集在一起， 提取共同的日志pattern，是能带来的直接收益。

• 有利于发现日志中的规律和共性问题，方便从海量日志中排查问题，定位故障
• 海量日志仅需少量日志模式表示，提取共性部分保留独立信息，减少存储成本

1.2.2 间接目标

日志聚类对于后续的功能比如日志异常检测是非常有帮助的，错误日志的异常检测需要建立在日志聚类的基础上。

• 异常检测：基于深度学习的日志异常检测；通过日志的聚类分析区分系统正常运行报错日志和系统故障日志，各类日志出现频率的时序变化，变更发布后是否有出现新增类型的日志报错等
• 根因分析：比如通过syslog日志来辅助定位机器故障，通过dmsg日志对潜在异常子机故障巡检

2. 产品形态

2.1 学术科研

以安灯数据集、群开发逻辑层日志为例，左边LogStr是原始日志，右侧signature是聚类之后的形态，针对每一类日志赋予一个标签logEvent*，相同标签的日志即为同一类。

2.2 行业竞品日志服务

对比竞品某厂的日志服务SLS产品形态较为成熟。SLS提供实时日志智能聚类(LogReduce)功能，采集文本日志时，将相似度高的日志聚集在一起， 提取共同的日志pattern；能够在搜索分析过程中帮助发现 日志的规律与特征 ，提升重要信息发现能力。对于日志的样式无任何限制，只会根据日志相似性，提取出通用Pattern，快速获取日志的整体概览。

功能特点：

1. 手动调整聚类精度：聚类偏向于多、则聚类结果分类细，pattern保留的细节多；
2. 过滤日志聚类：先经过 任意条件过滤 日志，再进行聚类，查看最后的日志数量
3. 日志聚类对比功能（Log compare）：查看原始日志：对聚类后的日志模式Pattern， 反查原始数据
4. 在新版本上线，往往希望知道， 有哪些新出现的日志类别，哪类日志在数量上有明显的抖动 ，这样的版本回归对比需求，可以使用LogReduce + cmp来满足。

3. 技术框架——基于图结构的聚类方法

基于图结构的日志聚类方法，包括基于文本分词、向量相似度以及最大连通子图等方法，对日志进行聚类并获取特征库；根据特征库中的类别特征对海量日志进行类别标记。

本节先介绍如何构建特征库，再介绍如何在线上和离线进行日志聚类，最后总结说明该方法的优缺点。

3.1 流程框图

如图，构建特征库注意包括三个步骤：日志向量化、确定日志相似关系和构建特征库。

3.1.1 日志结构化

采集原始日志，提取数据字段解析格式，比如时间、特殊字符、IP等。将半结构化、非结构化的原始日志转换成结构化日志

举例，一下两个syslog日志，按列可以结构化为时间戳、日志来源、日志内容等子弹，经过结构化处理之后变为下表的格式

3.1.2 构建分词库

获取所有结构化日志中包含的所有分词。预设规则，删除干扰词，包括但不限于IP地址、端口号、16进制数、url链接等等。将所有分词编号，构建分词库，如下表。

3.1.3 日志向量化

1. 根据分词库，将日志内容的分词用分词编号替换
2. 忽略未包含在词库中的分词，保持分词原有的相对顺序，将文本转换为向量

3.1.4 确定日志相似关系

构建最大连通子图，将向量化后的日志映射为图中一个点，计算点之间的相似度；若若两个日志向量相似，则日志向量之间存在一条边。注意，如果多个日志向量化之后的表示完全相同，则可删除重复的日志向量，减少重复的计算量。

如图示例，生成各个类别包含的日志向量集合，日志相似关系图中的每个最大连通子图定义为一个类，每一类包含的日志向量即该最大连通子图包含的点

相似性度量方法：最长公共子序列（注：也可采用余弦相似性等）

设A和B分别为两个日志向量A=(a1, a2, a3, ..., am)，B=(b1, b2, ..., bn)，LCS(A, B) 为两者的最长公共子序列；

举例说明，给定两个序列s1={1,3,4,5,6,7,7,8}，s2={3,5,7,4,8,6,7,8,2}，s1和s2的其中一个最长公共子序列是 {3,4,6,7,8}。

若该最长公共子序列的长度与两个日志的长度之比均大于各自的相似度阈值，则认为两者相似，其表达式为：

LCS(A, B) / |A| >= similarity_threshold，

LCS(A, B) / |B| >= similarity_threshold

其中|A|表示A日志向量的长度。

3.1.5 构建特征库

如上图，每个日志类别的特征为该类别包含的所有日志向量的最长公共子序列。举例，第一类label1={A, B, C}，则特征w1=LCS(A, B, C)

输入每个日志类别所包含的日志向量集合，输出特征库。

3.2 聚类应用

聚类应用的几个步骤：

1. 计算日志向量和特征库中各类别特征的相似度；若日志向量和特征符合相似度阈值要求，则将该日志标记为第labeli类，并输出携带标记的日志
2. 若日志向量与特征库中所有的特征都不相似，则将日志存放于故障知识库，并定期重新聚类，生成新的类别特征，以更新特征库
3. 根据最大连通子图确定最终的聚类数目、类别
4. 用特征库表示每一个类别，比如最长公共序列/余弦相似性的层次聚类

• 离线聚类分析：若日志向量与特征库中所有的特征都不相似，则将当前日志向量自成一类，或者直接输出当前日志结构化之后的文本形式

• 实时在线聚类：若新输入的日志存在新的分词，加更新词库，；若日志向量与特征库中所有的特征都不相似，则将当前日志向量自成一类，或者直接输出当前日志结构化之后的文本形式。

3.3 补充

3.3.1 优点

• 该方法无需人工指定聚类数据，相似度阈值可以人为设定，因此可以满足不同场景需求下的相似日志聚类
• 可对日志进行精准分类，支持海量日志数据的实时分类以及离线分类。

3.3.2 缺点

• 相似度计算方法：最长公共子序列的计算比较耗时，对于实时线上海量日志能够更快地聚类，这里未来有一定的优化空间。
• 干扰词的处理：该方法对于干扰词采用直接剔除的方法，过于简单粗暴。如果想保留部分IP等更多信息，可以在文本向量化之前增设人工规则，保留希望保留的信息。

3.3.3 向量空间余弦相似度

除了最长公共子序列的方法用于判定日志相似关系外，也可以采用诸如余弦相似度的计算方法。

余弦相似度(Cosine Similarity)用向量空间中两个向量夹角的余弦值作为衡量两个个体间差异的大小。余弦值越接近1，就表明夹角越接近0度，也就是两个向量越相似。

• 如图a和b两个向量的夹角很小，则说明a向量和b向量有很高的的相似性，极端情况下；
• 如果两个向量在方向上完全重合，则说明a向量和b向量代表的文本完全相的，或者完全相等；
• 如图a和b两个向量的夹角较大或者反方向，则说明a向量和b向量的相似性很低，或者完全不相似。

因此，我们可以通过夹角的大小，来判断向量的相似程度。夹角越小，就代表越相似。两个日志向量A、B的相似度计算公式如下

4. 总结

本文先介绍了日志使用场景，一线运维人员面对海量日志排查问题非常低效。然后介绍了日志聚类可以提供的便捷性，以及以竞品某厂的日志服务的较为成熟的产品形态。最后介绍了一种基于图结构的日志聚类方法。该方法采用了包括基于文本分词、向量相似度以及最大连通子图等技术，对日志进行聚类并获取特征库进而实现对海量日志进行类别标记的功能。关于日志聚类的更多方法将在后续详细介绍。

参考链接

1. https://blog.csdn.net/u012160689/article/details/15341303
2. https://toutiao.io/posts/pgzhae/preview
3. https://bbs.huaweicloud.com/blogs/106255