中国工商银行软件开发中心广州技术部
你是否经常为从海量日志中找到异常日志而苦恼？
你是否为服务不可用但告警系统未报警而焦虑？
你是否经常为日志告警系统发来的假报警而烦躁？
本文介绍了一种日志异常智能分析方法，解决传统基于正则匹配的告警系统开发工作量大、精确度不高的问题。希望能为大家带来一些帮助和启发。
1 引言
日志分析作为一种主要的故障排查手段，贯穿于程序开发的整个生命周期。目前银行系统日志分析的主要方法以人工排查和“正则匹配+自动上报”的自动化排查为主。但随着分布式系统日志量的显著增长，人工排查和基于正则的自动化排查手段越来越难以奏效，其局限性主要体现在以下方面：
-
当日志量大时，通过人工查找异常日志的方法难以实施。如一个典型的分布式系统，每小时可产生50G日志，通过人工手段难以排查。 -
如采用基于正则表达的自动化方法，则需要开发人员手工编写正则表达匹配程序，工作量极大且难以覆盖所有异常场景。 -
随着应用版本不断迭代，日志也在不断的更新，这可能使得以往的正则匹配模式失效。 -
正则匹配模式往往会出现假报警的情况。如在应用执行过程中存在一段用于检查上一步是否存在错误的程序，执行完后日志输出“ Error check completed. ”。该语句是一条系统正常日志输出，但若按正则匹配的方法，则可能误判触发告警。 -
对于日志频度异常，传统的正则表达方法无法奏效。例如，要捕获系统在某一时间段内大量出现full gc日志，首先需要人工预判会出现此类日志才会编写出对应的正则表达式并进行频度统计。对于预料之外的频度异常，无法使用正则匹配方法。
针对以上痛点问题，我们提出了一种基于文本聚类进行日志异常智能识别的方法，以满足人们对日志检测智能化的需求。
2 智能日志检测的解决思路
2.1 场景分析
-
找到系统异常时段附近的日志； -
凭借以往经验，找到故障时段日志是否存在与系统正常时的日志差异，差异部分即可能为异常日志； -
查看系统异常附近日志发生频度是否与正常时显著不同；
通过上述分析可以发现，自动化日志检测的关键问题是：
-
如何通过计算机算法归纳出系统正常与异常时的特征，并找出差异； -
如何通过统计学方法，有效统计系统正常时日志频率，从而判别出异常频率。
2.2 解决思路
针对上述提到的差异对比和频率统计问题，我们提出了以下解决思路：
3 智能日志检测实践
3.1 错误提示类日志检测
对于系统异常时，日志中出现错误提示类异常，其智能检测方法流程如下：
3.2 频度异常类日志检测
在应用运维过程中存在一类异常场景，即系统异常时并不会报错误日志，而会大量高频出现某类日志。如Java应用中某时间段内大量高频出现Full GC，导致服务不可用。对于该类场景，其自动检测方法如下：
1、对系统正常运行时日志进行文本聚类，得到日志对应的模板；
以上图为例，在指定时间窗口内出现了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生成日志所有时间窗口生成对应的向量，得到正常日志特征向量集。
[1,2,0]附近，而当系统发生大量GC时其向量可能为[10,0,0]，那么该异常向量远离正常向量簇中心，即可通过聚类方法识别出该GC大量出现的异常情况。
如上图所示，当异常发生时，异常特征向量往往远远偏离正常特征向量集，因此可以通过非监督学习聚类方法，如 Kmeans、DBScan、孤立森林等方法实现异常检测。
4 优点
-
模型能够从训练数据集中总结归纳出异常模式，而无需人工指定异常匹配模式，提升了异常识别的准确性； -
核心基于文本聚类算法识别，实现无需编写正则表达式即可得到异常日志特征，极大减少了研发运维人员工作量、提升了故障排查效率。 -
通过自动化对模型进行持续训练，可以使异常检测模型与应用版本同步升级，始终保持异常检测有效性；
还不过瘾？4月7日-8日，GOPS 2023 · 深圳站，招行上云实践专场，招商银行5位大咖首次披露招行 100% 上云历程，一次带你了解更多！
<< 右滑查看更多 >>
投稿邮箱：[email protected]，或添加联系人微信：greatops1118。
原文始发于微信公众号（高效运维）：跟正则表达式说 ByeBye！中国工商银行日志异常智能检测探索与实践
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论