跟正则表达式说 ByeBye！中国工商银行日志异常智能检测探索与实践

作者简介

中国工商银行软件开发中心广州技术部

你是否经常为从海量日志中找到异常日志而苦恼？
你是否为服务不可用但告警系统未报警而焦虑？
你是否经常为日志告警系统发来的假报警而烦躁？

本文介绍了一种日志异常智能分析方法，解决传统基于正则匹配的告警系统开发工作量大、精确度不高的问题。希望能为大家带来一些帮助和启发。

1 引言

日志分析作为一种主要的故障排查手段，贯穿于程序开发的整个生命周期。目前银行系统日志分析的主要方法以人工排查和“正则匹配+自动上报”的自动化排查为主。但随着分布式系统日志量的显著增长，人工排查和基于正则的自动化排查手段越来越难以奏效，其局限性主要体现在以下方面：

1. 当日志量大时，通过人工查找异常日志的方法难以实施。如一个典型的分布式系统，每小时可产生50G日志，通过人工手段难以排查。
2. 如采用基于正则表达的自动化方法，则需要开发人员手工编写正则表达匹配程序，工作量极大且难以覆盖所有异常场景。
3. 随着应用版本不断迭代，日志也在不断的更新，这可能使得以往的正则匹配模式失效。
4. 正则匹配模式往往会出现假报警的情况。如在应用执行过程中存在一段用于检查上一步是否存在错误的程序，执行完后日志输出“

   Error check completed.

   ”。该语句是一条系统正常日志输出，但若按正则匹配的方法，则可能误判触发告警。
5. 对于日志频度异常，传统的正则表达方法无法奏效。例如，要捕获系统在某一时间段内大量出现full gc日志，首先需要人工预判会出现此类日志才会编写出对应的正则表达式并进行频度统计。对于预料之外的频度异常，无法使用正则匹配方法。

针对以上痛点问题，我们提出了一种基于文本聚类进行日志异常智能识别的方法，以满足人们对日志检测智能化的需求。

2 智能日志检测的解决思路

2.1 场景分析

首先回归到人工如何找到异常日志的场景。当系统出现异常人工分析日志时，通常我们会按照如下流程操作：

1. 找到系统异常时段附近的日志；
2. 凭借以往经验，找到故障时段日志是否存在与系统正常时的日志差异，差异部分即可能为异常日志；
3. 查看系统异常附近日志发生频度是否与正常时显著不同；

通过上述分析可以发现，自动化日志检测的关键问题是：

1. 如何通过计算机算法归纳出系统正常与异常时的特征，并找出差异；
2. 如何通过统计学方法，有效统计系统正常时日志频率，从而判别出异常频率。

2.2 解决思路

对于从文本中提取特征问题，业界已经做了大量探索。目前业界一种主要解决思路是采用 Drain、Spell 等文本聚类的方法，将日志归纳为模板，在模板的基础上，记录日志发生的频率特征，从而实现日志文本特征的归纳。

针对上述提到的差异对比和频率统计问题，我们提出了以下解决思路：

1. 在差异对比方面，对系统正常工作时日志和系统异常时的日志分别聚类，得到正常特征集和存在异常的特征集。由于系统异常时段部分日志为正常日志，因此需要从存在异常的特征集中剔除正常特征集，剩下的则为异常特征集。后续新增日志可通过与异常特征集进行对比，实现告警。

2. 在频率统计方面，可按指定时间窗口对系统正常工作时特征匹配数量进行统计，生成正常特征向量集。后续新增日志形成的特征向量与正常特征向量集进行异常检测，若新增日志特征向量与正常特征向量集间距超过阈值，则触发告警。

具体实现方法如下。

3 智能日志检测实践

3.1    错误提示类日志检测

对于系统异常时，日志中出现错误提示类异常，其智能检测方法流程如下：

1、分别获取系统正常时段日志和系统异常时段日志作为训练数据集；

2、对日志文本采用 Drain、SPELL 等算法进行文本聚类，分别得到正常日志模板和存在异常日志模板；

以上图为例，原始的日志信息通过 spell 算法后，同类日志（如1,4）被聚合到了同一个模板(Event1)中，变量部分用*号表示。

在实际测试过程中，对某实际应用10万行编译日志进行聚类，最终可以得到40条模板。

3、由于异常时段日志中仍含有正常日志，因此对正常日志模板和存在异常的日志模板进行差异比对，从中提出正常日志模板，得到异常日志模板；经二次确认后，写入异常模板库。

如上图所示，系统异常时段进行文本聚类后，可以得到四个模板 Event1、Event3、Event4、Event6，而系统正常时段中也存在模板 Event1、Event4，故剔除后剩下Event3、Event6 为疑似异常日志。通过二次确认后，写入异常模型库。

4、对新增日志，将其与异常日志模板进行匹配，若匹配成功，则说明新增日志中含有异常。

3.2 频度异常类日志检测

在应用运维过程中存在一类异常场景，即系统异常时并不会报错误日志，而会大量高频出现某类日志。如Java应用中某时间段内大量高频出现Full GC，导致服务不可用。对于该类场景，其自动检测方法如下：

1、对系统正常运行时日志进行文本聚类，得到日志对应的模板；

2、指定t作为时间窗口，统计时间窗口内相同模板日志发生的次数，并生成向量。

以上图为例，在指定时间窗口内出现了3条日志，其中“ip: 192.168.2.1 pid:2845 start full gc”对应模板1，在时间窗口内出现了1次， “192.168.0.1 updated successfully”和“192.168.0.8 updated successfully”对应模板2，在时间窗口内出现了2次。而在时间窗口内有0条日志对应模板3，故生成的向量为[1,2,0]。

3、按照步骤2生成日志所有时间窗口生成对应的向量，得到正常日志特征向量集。

通过 KMeans、DBScan、孤立森林等聚类方法，检测其中的异常向量。如正常日志向量簇中心在[1,2,0]附近，而当系统发生大量GC时其向量可能为[10,0,0]，那么该异常向量远离正常向量簇中心，即可通过聚类方法识别出该GC大量出现的异常情况。

如上图所示，当异常发生时，异常特征向量往往远远偏离正常特征向量集，因此可以通过非监督学习聚类方法，如 Kmeans、DBScan、孤立森林等方法实现异常检测。

4 优点

1. 模型能够从训练数据集中总结归纳出异常模式，而无需人工指定异常匹配模式，提升了异常识别的准确性；
2. 核心基于文本聚类算法识别，实现无需编写正则表达式即可得到异常日志特征，极大减少了研发运维人员工作量、提升了故障排查效率。
3. 通过自动化对模型进行持续训练，可以使异常检测模型与应用版本同步升级，始终保持异常检测有效性；

---

还不过瘾？4月7日-8日，GOPS 2023 · 深圳站，招行上云实践专场，招商银行5位大咖首次披露招行 100% 上云历程，一次带你了解更多！

<<  右滑查看更多  >>

近期好文：

音乐永不停！且看QQ音乐高可用架构如何玩转混沌工程、可观测性

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱：[email protected]，或添加联系人微信：greatops1118。

点个“在看”，一年不宕机

原文始发于微信公众号（高效运维）：跟正则表达式说 ByeBye！中国工商银行日志异常智能检测探索与实践