基于Flume+Log4j+Kafka的日志采集架构方案（上）

Flume是一个完善、强大的日志采集工具，关于它的配置，在网上有不少现成的例子和资料，这里仅作简单说明再也不详细赘述。
Flume包含Source、Channel、Sink三个最基本的概念：

Source——日志来源，其中包括：Avro Source、Thrift Source、Exec Source、JMS Source、Spooling Directory Source、Kafka Source、NetCat Source、Sequence Generator Source、Syslog Source、HTTP Source、Stress Source、Legacy Source、Custom Source、Scribe Source以及Twitter 1% firehose Source。

Channel——日志管道，全部从Source过来的日志数据都会以队列的形式存放在里面，它包括：Memory Channel、JDBC Channel、Kafka Channel、File Channel、Spillable Memory Channel、Pseudo Transaction Channel、Custom Channel。

Sink——日志出口，日志将经过Sink向外发射，它包括：HDFS Sink、Hive Sink、Logger Sink、Avro Sink、Thrift Sink、IRC Sink、File Roll Sink、Null Sink、HBase Sink、Async HBase Sink、Morphline Solr Sink、Elastic Search Sink、Kite Dataset Sink、Kafka Sink、Custom Sink。

基于Flume的日志采集是灵活的，咱们能够看到既有Avro Sink也有Avro Source，既有Thrift Sink也有Thrift Source，这意味着咱们能够将多个管道处理串联起来，以下图所示

串联的意义在于，咱们能够将多个管道合并到一个管道中最终输出到同一个Sink中去，以下图：

上面讲述了Source和Sink的做用，而Channel的做用在于处理不一样的Sink，假设咱们一个Source要对应多个Sink，则只须要为一个Source创建多个Channel便可，以下所示：

一个Source若是想要输出到多个Sink中去，就须要创建多个Channel进行介入并最终输出，经过上面这几张图，咱们能够很好的理解Flume的运行机制，咱们在这里也就点到为止，详细的配置能够在官网或者在网上搜索到、查看到。

通常状况下，咱们使用 Exec Source对log文件进行监控，这样作确实是比较简单，可是并不方便，咱们须要在每一台要监控的服务器上部署Flume，对运维来说万一目标日志文件发生IO异常（例如格式改变、文件名改变、文件被锁），也是很痛苦的，所以咱们最好能让日志直接经过Socket发送出去，而不是存放在本地，这样一来，不只下降了目标服务器的磁盘占用，还可以有效的防止文件IO异常，而Kafka就是一个比较好的解决方案，具体的架构以下图所示：

由上图能够看到，日志最终流向了两个地方：HBase Persistence和Realtime Processor，而至于为何不用Kafka直接与Storm进行通讯的缘由是为了将Sotrm逻辑和日志源经过Flume进行隔离，在Storm中对日志进行简单的分析后，将结果扔进 Rabbit MQ 中供 WEB APP消费。

HBase Persistence就是将原始的日志记录在HBase中以便回档查询，而Realtime Processor则包含了实时的日志统计以及错误异常邮件提醒等功能。

下节咱们重点讲述程序实现