Flume作为一个日志收集工具，非常轻量级，基于一个个Flume Agent，能够构建一个很复杂很强大的日志收集系统，它的灵活性和优势，主要体现在如下几点： 模块化设计：在其Flume Agent内部可以定义三种组件：Source、Channel、Sink 组合式设计：可以在Flume Agent中根据业务需要组合Source、Channel、Sink三种组件，构建相对复杂的日志流管道 插件式设计：可以通过配置文件来编排收集日志管道的流程，减少对Flume代码的侵入性 可扩展性：我们可以根据自己业务的需要来定制实现某些组件（Source、Channel、Sink） 支持集成各种主流系统和框架：像Hadoop、HBase、Hive、Kafka、ElasticSearch、Thrift、Avro等，都能够很好的和Flume集成 高级特性：Failover、Load balancing、Interceptor等 有关Flume的相关内容，可以参考官网文档，或者通过阅读我之前写的文章《Flume(NG)架构设计要点及配置实践》来快速了解。 为什么要对Flume日志收集系统进行分层设计 基于Flume设计实现分层日志收集系统，到底有什么好处呢？我们可以先看一下，如果不分层，会带来哪些问题： 如果需

Flume NG是一个分布式、可靠、可用的系统，它能够将不同数据源的海量日志数据进行高效收集、聚合、移动，最后存储到一个中心化数据存储系统中。由原来的Flume OG到现在的Flume NG，进行了架构重构，并且现在NG版本完全不兼容原来的OG版本。经过架构重构后，Flume NG更像是一个轻量的小工具，非常简单，容易适应各种方式日志收集，并支持failover和负载均衡。 架构设计要点 Flume的架构主要有一下几个核心概念： Event：一个数据单元，带有一个可选的消息头 Flow：Event从源点到达目的点的迁移的抽象 Client：操作位于源点处的Event，将其发送到Flume Agent Agent：一个独立的Flume进程，包含组件Source、Channel、Sink Source：用来消费传递到该组件的Event Channel：中转Event的一个临时存储，保存有Source组件传递过来的Event Sink：从Channel中读取并移除Event，将Event传递到Flow Pipeline中的下一个Agent（如果有的话） Flume NG架构，如图所示： 外部系统产生日志，直接通过Flume的Agent的Source组件将事件（如日志行）发送到中间临时的channel组件，最后传