Dbus中日志类数据源的实现

什么是日志数据？

业界日志收集、结构化、分析工具方案很多，例如：Logstash、Filebeat、Flume、Fluentd、Chukwa. scribe、Splunk等，各有所长。在结构化日志这个方面，大多采用配置正则表达式模板：用于提取日志中模式比较固定、通用的部分，例如日志时间、日志类型、行号等。对于真正的和业务比较相关的信息，这边部分是最重要的，称为message部分，我们希望使用可视化的方式来进行结构化。

例如：对于下面所示的类log4j的日志：

如果用户想将上述数据转换为如下的结构化数据信息：

我们称这样的日志为“数据日志”

 

DBUS设计的数据日志同步方案如下：

1. 日志抓取端采用业界流行的组件（例如Logstash、Flume、Filebeat等）。一方面便于用户和业界统一标准，方便用户的整合；另一方面也避免无谓的重造轮子。抓取数据称为原始数据日志（raw data log）放进Kafka中，等待处理。
2. 提供可视化界面，配置规则来结构化日志。用户可配置日志来源和目标。同一个日志来源可以输出到多个目标。每一条“日志源-目标”线，中间数据经过的规则处理用户根据自己的需求来自由定义。最终输出的数据是结构化的，即：有schema约束，可以理解为类似数据库中的表。
3. 所谓规则，在DBUS中，即“规则算子”。DBUS设计了丰富易用的过滤、拆分、合并、替换等算子供用户使用。用户对数据的处理可分多个步骤进行，每个步骤的数据处理结果可即时查看、验证；可重复使用不同算子，直到转换、裁剪得到自己需要的数据。
4. 将配置好的规则算子组运用到执行引擎中，对目标日志数据进行预处理，形成结构化数据，输出到Kafka，供下游数据使用方使用。

系统流程图如下所示：

 

根据配置，我们支持同一条原始日志，能提取为一个表数据，或者可以提取为多个表数据。

每个表是结构化的，满足相同的schema。

• 每个表是一个规则 算子组的合集，可以配置1个到多个规则算子组
• 每个规则算子组，由一组规则算子组合而成

拿到一条原始数据日志， 它最终应该属于哪张表呢？

每条日志需要与规则算子组进行匹配：

• 符合条件的进入规则算子组的，最终被规则组转换为结构化的表数据。
• 不符合的尝试下一个规则算子组。
• 都不符合的，进入unknown_table表。