导读:数据总线DBus的总体架构中主要包括六大模块,分别是:日志抓取模块,增量转换模块,全量抽取程序,日志算子处理模块,心跳监控模块,Web管理模块。六大模块各自的功能相互连接,构成DBus的工作原理:通过读取RDBMS增量日志的方式来实时获取增量数据日志(支持全量拉取),基于Logstash,水槽,filebeat等抓取工具来实时获得数据,以可视化的方式对数据进行结构化输出。本文主要介绍的是DBus中基于可视化配置的日志结构化转换实现的部分。
一、结构化日志的原理
1.1源端日志抓取
DBus可以对接多种日志数据源,例如:Logstash,水槽,Filebeat等。上述组件都是业界比较流行的日志抓取工具,一方面便于用户和业界统一标准,方便用户技术方案的整合,另一方面也避免了无谓的重复造轮子。抓取的数据我们称为原始数据日志(原始数据日志),由抓取组件将其写入卡夫卡中,等待DBus后续处理。
1.2可视化配置规则,使日志结构化
用户可自定义配置日志源和目标端。同一个日志源的数据可以输出到多个目标端。每一条“日志源——目标端”线,用户可以根据自己的需要来配置相应的过滤规则。经过规则算子处理后的日志是结构化的,即:有模式约束,类似于数据库中的表。
1.3规则算子
DBus设计了丰富易用的算子,用于对数据进行定制化操作。用户对数据的处理可分为多个步骤进行,每个步骤的数据处理结果可即时查看,验证,并且可重复使用不同算子,直到转换,裁剪出自己需要的数据。
1.4执行引擎
将配置好的规则算子组应用到执行引擎中,对目标日志数据进行预处理,形成结构化数据,输出到卡夫卡,供下游数据使用方使用。系统流程图如下所示:
根据DBus日志设计原则,同一条原始日志,可以被提取到一个或多个表中,每个表是结构化的,满足相同的模式约束。
-
<李>每个表是一个规则算子组的集合,每个表可以拥有一个或多个规则算子组;李
<李>每个规则算子组,由一组规则算子组合而成,每个算子具有独立性;李
对于任意一条原始数据日志(原始数据日志),它应该属于哪张表呢?
假如用户定义了若干张逻辑表(T1, T2…),用于抽取不同类型的日志,那么,每条日志需要与规则算子组进行匹配:
-
<李>进入某张表T1的所有规则算子组的执行过程李
<李>符合条件的进入规则算子组,并且被执行引擎转换为结构化的表数据李
<李>不符合提取条件的日志尝试下一个规则算子组
<李>对于T1的所有规则算子组,如果都不满足要求,则进入下一张表T2的执行过程,以此类推李
<李>如果该条日志不符合任何一张表的过滤规则,则进入_unknown_table_表
例如,对于同一条应用日志,其可能属于不止一个规则组或表,而在我们定义的规则组或表中,只要其满足过滤条件,该应用日志就可以被规则组提取,即保证了同一条应用日志可以同属于不同的规则组或表。
规则算子是对数据进行过滤,加工,转换的基本单元。常见的规则算子如上图所示。
算子之间具有独立性,算子之间可以任意组合使用,从而可以实现许多复杂的,高级的功能,通过对算子进行迭代使用,最终可以实现对任意数据进行加工的目的。用户可以开发自定义算子,算子的开发非常容易,用户只要遵循基本接口原则,就可以开发任意的算子。
二,DBus日志处理实例
以DBus集群环境为例,DBus集群中有两台机器(即主从)部署了心跳程序,用于监控,统计,预警等,心跳程序会产生一些应用日志,这些应用日志中包含各类事件信息,假如我们想要对这些日志进行分类处理并结构化到数据库中,我们就可以采用DBus日志程序对日志进行处理。
DBus可以接入多种数据源(Logstash、水槽、Filebeat等),此处以Logstash为例来说明如何接入DBus的监控和报警日志数据。
