最近对日志系统的采集机制进行了重构，增强了对单一主机上多个日志源采集的便捷性。

重构之前

重构之前的设计以日志类型为中心，一个日志类型对应一个独立的flume的配置模板，一个日志类型的一个日志源（具体到某个节点上特定的日志文件）对应一个flume配置文件（也即一个flume agent）。flume配置模板主要针对这个日志类型的日志文件名称、是否存在多行日志、日志首字符、目标接收方有关的配置等固定属性。光靠这些配置还不够，因为这些日志类型所对应的日志会存在于各个具体的主机节点以及可能不同的文件系统路径下，所以针对某个日志类型的日志源还需要配置日志文件路径、日志文件名称的模式、采集器元数据存储路径等动态属性。

这里管控台的设计完全没有按照flume里source、channel、sink区分开来。sink的配置是混合在flume配置模板里。

管控台的功能逻辑图：

重构前zk Path设计：

重构前采集器的物理部署图：

重构之后

我们的目标是减少同一个物理主机上采集器的部署成本，最好能一个物理主机部署一个采集器，而这个采集器支持多个日志源的采集。正好在当前版本的flume(v1.6.0)是支持 一个agent里多个日志流。因此，在重构的时候，改为以agent为中心，并重新规划了管控台的功能：

• 采集源模板
• 采集器
• 采集源
• 采集槽

重构之后管控台的功能逻辑图：

重构后的zk path设计：

重构后的物理部署图：

总结

其实不难看出，管控台的功能逻辑以生成flume配置文件为目标。所以设计的变更主要体现在管控台如何组织和管理这些元数据信息。