进阶必看！日志解析的可靠与可信

在《前方高能！日志解析的深渊与救赎》（点击可回顾）一文中，向大家阐述了日志自动化解析之痛，以及如何实现日志结构化。然而只有结构化是远远不够的。本文将继续此话题，讲述如何快速实现高质量的日志解析，挖掘日志中的所有宝藏。

日志结构化的质量是可观察性的关键一环

IT运维人的热点话题是什么？自然是：“可观察性”，以及支撑起“可观察性”的三驾马车：Trace、Log、Metric（指标）。

1.Trace是现在绝对的热门，大多数Trace的形式其实和日志是类似的，有Skywalking、Zipkin这些框架以及OpenTracing等规范的加持，Trace的数据天生就是完全结构化的，从内容到格式高度规范化，因此对Trace数据的分析和利用不存在任何障碍。

2.Metric数据结构简单，有各种时间序列分析算法，是AIOps产品做异常检测和告警的主要数据来源，也有很多使用场景。

3.日志就没有这么幸运了，内容和结构都缺少统一的规范，严重地阻碍了日志的利用。除了在事后分析故障原因的时候利用一下搜索功能，代替在每台日志源主机上的cat xxx.log|grep|sed这样的shell命令，其它有效的使用场景寥寥无几。

显然，现在三驾马车得到的待遇不太一样。在运维中，Log应该发挥最关键的作用。Metric是发现问题（What），Trace是哪里有问题（Where），Log才是解决为什么出问题（Why）。

十多年的安全和运维日志分析实践让我们深有体会：要想充分发挥日志的价值，可靠、可信任的log解析是一道绕不过的坎。就是说：

结构化是日志分析的基本前提，然而只有结构化是远远不够的。

很多用户也对日志做了结构化，为什么仍然摆脱不了只有search可用的窘境呢？计算机科学中有一句经常被提到的话“Garbage in, Garbage out”，大概就是回答这个问题的最佳答案。已经做了结构化的日志，为什么还被称为Garbage，还缺少了什么？

完整：不能漏，日志中的可用信息都提取成字段；

准确：不能错，一条日志里面的字段提取不能错；

及时：日志源发生变更、出现新日志或者日志格式发生变化，要能实时发现和调整。

不能漏，字段的数量决定了分析的深度

一般日志管理系统除了实现日志集中采集和存储以外，还提供了日志分析能力：

1.关键词搜索，常用于交互式的人工分析；

2.类SQL的查询语句，可以做定期执行的告警规则和自动报表；

3.聚合统计，利用日志中的字段统计成指标（metric），进行分析和告警；

4.规则引擎，自动执行的告警；

5.机器学习，高级的异常检测和预测。

除了“关键词搜索”以外，其他能力都要基于结构化后的字段实现。可见，字段的数量越多，分析的维度和能力越强，分析可能达到的自动化程度就越高。

在安全运营领域，大部分SIEM系统都依赖于规则引擎，规则引擎的输入则依赖于日志结构化后的字段。在运维领域，客户投入了巨大的成本对日志实现了集中采集，使用正则表达式对个别日志进行解析，提取了一些字段做可视化或几个分析场景，对基于日志进行故障根源分析寄予厚望。随着日志源的变更、升级，正则表达式也逐渐疏于更新，提取的字段的准确性也随之下降，更别提基于这些字段进行告警或者根源分析了。

可以有一点作用的就是关键词搜索，这也是为什么大多数日志管理系统都是基于一个全文搜索引擎，例如ES，splunk等等。因为搜索对于日志管理系统的价值体现来说，无异于一根救命稻草。

不能错，解析质量是一切的前提

有了足够多的字段，还需要解析的质量足以生成可信的解析结果。如果没有准确可靠日志结构化，则：

1.可视化不好做；

2.异常检测不好做；

3.根源分析不好做。

通过几个实际的例子来说明解析质量的重要性。

第一个例子：准确性

一般认为应用日志的解析难度很大程度上是由于软件开发规范的欠缺造成的，那么，在微软的Windows上面，情况会有所改变吗，答案是：不。

这是一条windows 的安全日志：

Dec  8 17:55:00 10.17.14.159 daemon.notice 10.17.14.159 10.17.14.159  evtsys: Security: 562: NT AUTHORITY\SYSTEM: 关闭的句柄: 对象服务器: Security 句柄 ID: 8040 进程 ID: 780 图像文件名: C:\WINDOWS\system32\svchost.exe AUDIT_SUCCESS 

核心内容是若干冒号分割的key-value对，这种半结构化的日志为解析带来了更大的麻烦，例如上面的这种日志，所需要提取的字段虽然已经是结构化的了，但是字段的顺序可能会发生变化，甚至包含的Key-Value对的数量也会变化。

第二个例子，完整性

完整性：需要提取的信息可能包含在多种日志中，这几种日志格式要全部正确解析，才能保证要提取的信息的完整性。

例如：在下面这种应用日志中，包含了服务接口的名称以及处理时间，按照服务接口名称作聚合，可以统计每一个接口的性能（响应时间）指标，再利用机器学习引擎或者规则作一个告警规则。

[2022-02-27 12:30:08:671][INFO][sp.xxx.WfProcessService] 调用BPM获取下一环节所有分支cost:4ms,获取下一环节信息花费cost:0ms

如果使用正则表达式，完成这条日志的解析并不难：

\[(?[^\]]+)\]\[(?[^\]]+)\]\[.*\.(?[^\]]+)\].*cost\:(?\d+)ms\,.*cost\:(?\d+).*

但是，上线后，很快就发现，每一种serivce的日志都是在对应的代码中生成的，手写代码的随意性导致几乎每一种service的日志格式都不一样。

面对这么多的格式，人工很难穷举，特别是调用频率很低的接口，对应的日志也很少，容易被遗漏掉。如果不找全格式，没有数据完整性，最后的统计数据就不对，告警就没有意义。

第三个例子：变更

业务系统的版本、架构、功能是在不停地变化的。变更的频率越来越高，总是让日志工程师心惊胆战，变更以后，日志的解析就出错了，响应的告警规则就失效了，更糟糕的是可能到了真正出现故障或者安全事件，出现告警漏报的时候才发现。告警规则设计的再完备，也会形同虚设，还要一条一条地重新排查日志，解析问题。系统变更、升级、日志格式变化，导致日志出现结构性的变化，提取字段出错。

日志是一个巨大的信息金矿，要想挖掘它，我们得有一个好的工具，把日志的自动化分析做好，就朝着故障根源的自动化分析大大地迈进了一步。现在，日志的结构化是这条道路上的一个障碍。

如何克服这个障碍，我们需要一个这样的日志解析工具：

1.快速、方便，不需要投入很大的计算资源和工作量；

2.无代码，不需要专职的日志工程师；

3.解析质量有保证，准确、实时，能够实时感知日志格式的变化。

融天精灵智能日志解析系统EZLogic就是一个这样的工具，我们将在下一篇详细介绍EZLogic是如何跨越这个障碍的。