从开源日志解析引擎到"Botu"

回顾

2000 年，笔者走出大学校门机缘巧合的进入了梦想中的网络安全行业。阴差阳错间，没有做成彼时最流行的防火墙产品，而是投身到了以日志和数据为主的安全审计类产品赛道。也成为行业最早一批研究日志采集与处理技术的从业者。

对于日志采集与处理而言，最令人头疼的就是千变万化的日志格式。由于要对接的设备和软件类型太多，版本太多，所以全部通过编程进行对接完全是不现实的。更麻烦的是，很多系统的日志格式是可以定义的，比如：采用 W3C 标准的日志、Apache Tomcat 的日志等。还有些日志中的时间格式是可以调整的，这都给日志的解析处理带来了巨大的困难。

早期，笔者团队采用过 Lex&Yacc 技术来扩展各类日志的解析工作。这的确比编程更容易适配日志的变化。但实施过程中，也经常碰到需要调整解析的工作。于是需要重新编译、发布，相当的麻烦。

2005 年左右，Arcsight 进入中国，其技术令国内厂商打开眼界，并纷纷效仿。日志解析方面，其提供了一套自有的解析脚本语言，可以方便的在客户现场进行日志格式适配。这大大降低了日志审计、SEIM、安管等依托于日志数据的产品的实施成本。笔者团队也效仿此类思路，研发了基于 XML 语法结构以及正则表达式技术的日志解析语言，用来适配解析各类日志，一晃技术就用了十几年。

2011 年左右，大数据技术的兴起，让 LogStash，Flume 等开源日志采集及解析工具进入技术人员的视野。安全圈的不少厂商开始拥抱开源，纷纷摒弃自研，迅速利用开源技术增强产品的能力。一时间，产品技术同质化化严重，指标参数以无法让大家分出伯仲。很难评价此事的利弊。

但利用开源，也并非诸事顺遂，比如采用 LogStash 技术的厂商。LogStash 的 Grok 技术，使得日志的解析工作能够非常方便的在管理界面中进行配置，但这样的解析匹配无疑会降低日志的解析效率。因为绝大多数日志都需要多次尝试，才可能被正确的解析。网络上，可以搜到大量对 LogStash 性能不足的探讨文章。Flume 应该是目前应用最为广泛的日志采集工具，其使用 Morphline 插件实现对日志的解析。Morphline 采用了一种类似 Json 结构的语法格式，与绝大多数开发语言不同，这无疑会增加其语言的学习成本。

Botu

Botu 是笔者 2021 年应朋友需求重新开发的一款专用于数据解析与封装的脚本语言。设计的目标不仅仅是可以解析日志，同时也可以解析网页等各类数据。Botu 项目已经在朋友的产品中使用，得到了工业级应用的验证，可以放心使用。近期开源 Botu 是受到了技术圈讨论的启发，将项目贡献出来，方便大家在 AI 时代进行网络安全相关的研究。项目地址 Botuq，欢迎大家下载，应用。

其实，已经有了这么多开源的日志解析实现，为什么还要使用 Botu 呢？这里，Botu 给大家提供了几个理由：

1.语法结构更接近通用编程语言

Botu 可以被视为一款面向数据解析与封装的 DSL。其语法上尽量采用了与传统编程语言相近的设计。比如：其支持 If，While，For 等常用的语法表达式，可以大大降低使用者的学习成本。

2.动态“执行”优化

在编写日志解析时，为了能够提升日志解析速度，往往会采用分层解析的方式。即第一层粗解，第二层根据第一层解析出的特征进行二次解析。如下：

// 飞塔防火墙botu("Firewall/Fotinet/Firewall/Syslog") {    patternParse(MS_SRC_DATA, "^\\<(?<pri>\\d+)\\>(?<detail>.*)");    sev = parseSyslogSeverity(pri);    splitParse(detail, ' ', '"', '"', "=");    time = strFormat("%s %s", date, time);    if (type == "utm") {        if(subtype == "dlp") {            pack("event") {              ......            }        } else if (subtype=="app-ctrl") {            pack("event") {              ......            }    ......

这种情况下，需要大量用到条件分支语句。我们知道，条件分支语句在执行时需要依次匹配，判断数据是否满足条件。当匹配条件需要比较大的计算量时，比如需要进行正则匹配时，分支条件如果与实际的日志搭配不好，就会产生很多无效的计算。比如客户环境里大量的日志正好都匹配解析脚本的最后一个分支，那么大量的无效匹配就会拉低整个日志采集处理的效率。(注：日志采集处理的速度是面向日志应用类产品的核心指标之一)。Botu 提供了一种 Ifo 语法表达式，该表达式与 If 的应用场景一致，唯一的区别是，其在运行时，会根据数据的条件匹配情况，动态调整匹配顺序，从而达到最优的匹配效率。

3.高效的数据封装

所有日志解析工具的最后一步都是将解析结果打包成一个统一的结构，然后进行输出。很多解析工具为了通用性考虑，将输出结果表达为 Map 结构。这种结构的自由度极高，非常方便程序间交换数据，处理数据。但其性能的损失会比较大。Botu 设计采用了数组的方式打包数据，数组结构比 Map 结构存储更紧凑，访问速度也更快。实测性能差异可以达到 1 个数量级。唯一的不足是，对后续数据处理的编程要求会高一些，但面对其提升的速度，应该是可以取舍权衡的。

4.其它

Botu 项目缺省给出了笔者团队多年积累整理的日志解析后的结构模式。该结构模式试图寻找一种平衡，在字段的数量与解析的全面性中找到一个平衡点。一方面，不苛求将日志中所有的信息都进行解析描述，以免造成结构字段的膨胀。一方面，尽量解析并保存那些对业务应用有帮助的字段，从而避免虽然解析了很多字段，但实际无法有效应用的问题。

Botu 项目缺省留下了 10 个国内安全设备的日志解析文件，其余还有 180 个设备解析文件没有共享出来，有试用意愿的朋友可以通过 HuggingFists 系统了解试用。可通过下面的视频先进行初步了解：190种Syslog日志随心采。由于开源项目跟 HuggingFists 内部用的解析能力并不完全一致，迁移起来比较费力，所以有对剩余 180 个设备感兴趣的朋友，可以通过 support@datayoo.org 给我们发邮件联系。

关于 Botu 更多的内容可以通过Botuq项目了解。