基于Flume的美团日志收集系统(一)架构和设计

转自：http://www.aboutyun.com/thread-8317-1-1.html

问题导读：

1.Flume-NG与Scribe对比，Flume-NG的优点在什么地方？
2.架构设计考虑须要考虑什么问题？
3.Agent死机该如何解决？
4.Collector死机是否会有影响？
5.Flume-NG可靠性(reliability)方面作了哪些措施？

美团的日志收集系统负责美团的全部业务日志的收集，并分别给Hadoop平台提供离线数据和Storm平台提供实时数据流。美团的日志收集系统基于Flume设计和搭建而成。

《基于Flume的美团日志收集系统》将分两部分给读者呈现美团日志收集系统的架构设计和实战经验。

第一部分架构和设计，将主要着眼于日志收集系统总体的架构设计，以及为何要作这样的设计。

第二部分改进和优化，将主要着眼于实际部署和使用过程当中遇到的问题，对Flume作的功能修改和优化等。

1 日志收集系统简介

日志收集是大数据的基石。

许多公司的业务平台天天都会产生大量的日志数据。收集业务日志数据，供离线和在线的分析系统使用，正是日志收集系统的要作的事情。高可用性，高可靠性和可扩展性是日志收集系统所具备的基本特征。

目前经常使用的开源日志收集系统有Flume, Scribe等。Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，目前已是Apache的一个子项目。Scribe是Facebook开源的日志收集系统，它为日志的分布式收集，统一处理提供一个可扩展的，高容错的简单方案。

2 经常使用的开源日志收集系统对比

下面将对常见的开源日志收集系统Flume和Scribe的各方面进行对比。对比中Flume将主要采用Apache下的Flume-NG为参考对象。同时，咱们将经常使用的日志收集系统分为三层（Agent层，Collector层和Store层）来进行对比。

[td]

对比项	Flume-NG	Scribe
使用语言	Java	c/c++
容错性	Agent和Collector间，Collector和Store间都有容错性，且提供三种级别的可靠性保证；	Agent和Collector间, Collector和Store之间有容错性；
负载均衡	Agent和Collector间，Collector和Store间有LoadBalance和Failover两种模式	无
可扩展性	好	好
Agent丰富程度	提供丰富的Agent，包括avro/thrift socket, text, tail等	主要是thrift端口
Store丰富程度	能够直接写hdfs, text, console, tcp；写hdfs时支持对text和sequence的压缩；	提供buffer, network, file(hdfs, text)等
代码结构	系统框架好，模块分明，易于开发	代码简单

3 美团日志收集系统架构

美团的日志收集系统负责美团的全部业务日志的收集，并分别给Hadoop平台提供离线数据和Storm平台提供实时数据流。美团的日志收集系统基于Flume设计和搭建而成。目前天天收集和处理约T级别的日志数据。

下图是美团的日志收集系统的总体框架图。

<ignore_js_op>  

a. 整个系统分为三层：Agent层，Collector层和Store层。其中Agent层每一个机器部署一个进程，负责对单机的日志收集工做；Collector层部署在中心服务器上，负责接收Agent层发送的日志，而且将日志根据路由规则写到相应的Store层中；Store层负责提供永久或者临时的日志存储服务，或者将日志流导向其它服务器。

b. Agent到Collector使用LoadBalance策略，将全部的日志均衡地发到全部的Collector上，达到负载均衡的目标，同时并处理单个Collector失效的问题。

c. Collector层的目标主要有三个：SinkHdfs, SinkKafka和SinkBypass。分别提供离线的数据到Hdfs，和提供实时的日志流到Kafka和Bypass。其中SinkHdfs又根据日志量的大小分为SinkHdfs_b，SinkHdfs_m和SinkHdfs_s三个Sink，以提升写入到Hdfs的性能，具体见后面介绍。

d. 对于Store来讲，Hdfs负责永久地存储全部日志；Kafka存储最新的7天日志，并给Storm系统提供实时日志流；Bypass负责给其它服务器和应用提供实时日志流。

下图是美团的日志收集系统的模块分解图，详解Agent, Collector和Bypass中的Source, Channel和Sink的关系。

<ignore_js_op>  

a. 模块命名规则：全部的Source以src开头，全部的Channel以ch开头，全部的Sink以sink开头；

b. Channel统一使用美团开发的DualChannel，具体缘由后面详述；对于过滤掉的日志使用NullChannel，具体缘由后面详述；

c. 模块之间内部通讯统一使用Avro接口；

4 架构设计考虑

下面将从可用性，可靠性，可扩展性和兼容性等方面，对上述的架构作细致的解析。

4.1 可用性(availablity)

对日志收集系统来讲，可用性(availablity)指固定周期内系统无端障运行总时间。要想提升系统的可用性，就须要消除系统的单点，提升系统的冗余度。下面来看看美团的日志收集系统在可用性方面的考虑。

4.1.1 Agent死掉

Agent死掉分为两种状况：机器死机或者Agent进程死掉。

对于机器死机的状况来讲，因为产生日志的进程也一样会死掉，因此不会再产生新的日志，不存在不提供服务的状况。

对于Agent进程死掉的状况来讲，确实会下降系统的可用性。对此，咱们有下面三种方式来提升系统的可用性。首先，全部的Agent在supervise的方式下启动，若是进程死掉会被系统当即重启，以提供服务。其次，对全部的Agent进行存活监控，发现Agent死掉当即报警。最后，对于很是重要的日志，建议应用直接将日志写磁盘，Agent使用spooldir的方式得到最新的日志。

4.1.2 Collector死掉

因为中心服务器提供的是对等的且无差异的服务，且Agent访问Collector作了LoadBalance和重试机制。因此当某个Collector没法提供服务时，Agent的重试策略会将数据发送到其它可用的Collector上面。因此整个服务不受影响。

4.1.3 Hdfs正常停机

咱们在Collector的HdfsSink中提供了开关选项，能够控制Collector中止写Hdfs，而且将全部的events缓存到FileChannel的功能。

4.1.4 Hdfs异常停机或不可访问

假如Hdfs异常停机或不可访问，此时Collector没法写Hdfs。因为咱们使用DualChannel，Collector能够将所收到的events缓存到FileChannel，保存在磁盘上，继续提供服务。当Hdfs恢复服务之后，再将FileChannel中缓存的events再发送到Hdfs上。这种机制相似于Scribe，能够提供较好的容错性。

4.1.5 Collector变慢或者Agent/Collector网络变慢

若是Collector处理速度变慢（好比机器load太高）或者Agent/Collector之间的网络变慢，可能致使Agent发送到Collector的速度变慢。一样的，对于此种状况，咱们在Agent端使用DualChannel，Agent能够将收到的events缓存到FileChannel，保存在磁盘上，继续提供服务。当Collector恢复服务之后，再将FileChannel中缓存的events再发送给Collector。

4.1.6 Hdfs变慢

当Hadoop上的任务较多且有大量的读写操做时，Hdfs的读写数据每每变的很慢。因为天天，每周都有高峰使用期，因此这种状况很是广泛。

对于Hdfs变慢的问题，咱们一样使用DualChannel来解决。当Hdfs写入较快时，全部的events只通过MemChannel传递数据，减小磁盘IO，得到较高性能。当Hdfs写入较慢时，全部的events只通过FileChannel传递数据，有一个较大的数据缓存空间。

4.2 可靠性(reliability)

对日志收集系统来讲，可靠性(reliability)是指Flume在数据流的传输过程当中，保证events的可靠传递。

对Flume来讲，全部的events都被保存在Agent的Channel中，而后被发送到数据流中的下一个Agent或者最终的存储服务中。那么一个Agent的Channel中的events何时被删除呢？当且仅当它们被保存到下一个Agent的Channel中或者被保存到最终的存储服务中。这就是Flume提供数据流中点到点的可靠性保证的最基本的单跳消息传递语义。

那么Flume是如何作到上述最基本的消息传递语义呢？

首先，Agent间的事务交换。Flume使用事务的办法来保证event的可靠传递。Source和Sink分别被封装在事务中，这些事务由保存event的存储提供或者由Channel提供。这就保证了event在数据流的点对点传输中是可靠的。在多级数据流中，以下图，上一级的Sink和下一级的Source都被包含在事务中，保证数据可靠地从一个Channel到另外一个Channel转移。

<ignore_js_op>  

其次，数据流中 Channel的持久性。Flume中MemoryChannel是可能丢失数据的（当Agent死掉时），而FileChannel是持久性的，提供相似mysql的日志机制，保证数据不丢失。

4.3 可扩展性(scalability)

对日志收集系统来讲，可扩展性(scalability)是指系统可以线性扩展。当日志量增大时，系统可以以简单的增长机器来达到线性扩容的目的。

对于基于Flume的日志收集系统来讲，须要在设计的每一层，均可以作到线性扩展地提供服务。下面将对每一层的可扩展性作相应的说明。

4.3.1 Agent层

对于Agent这一层来讲，每一个机器部署一个Agent，能够水平扩展，不受限制。一个方面，Agent收集日志的能力受限于机器的性能，正常状况下一个Agent能够为单机提供足够服务。另外一方面，若是机器比较多，可能受限于后端Collector提供的服务，但Agent到Collector是有Load Balance机制，使得Collector能够线性扩展提升能力。

4.3.2 Collector层

对于Collector这一层，Agent到Collector是有Load Balance机制，而且Collector提供无差异服务，因此能够线性扩展。其性能主要受限于Store层提供的能力。

4.3.3 Store层

对于Store这一层来讲，Hdfs和Kafka都是分布式系统，能够作到线性扩展。Bypass属于临时的应用，只对应于某一类日志，性能不是瓶颈。

4.4 Channel的选择

Flume1.4.0中，其官方提供经常使用的MemoryChannel和FileChannel供你们选择。其优劣以下：

• MemoryChannel: 全部的events被保存在内存中。优势是高吞吐。缺点是容量有限而且Agent死掉时会丢失内存中的数据。
• FileChannel: 全部的events被保存在文件中。优势是容量较大且死掉时数据可恢复。缺点是速度较慢。

上述两种Channel，优缺点相反，分别有本身适合的场景。然而，对于大部分应用来讲，咱们但愿Channel能够同提供高吞吐和大缓存。基于此，咱们开发了DualChannel。

• DualChannel：基于 MemoryChannel和 FileChannel开发。当堆积在Channel中的events数小于阈值时，全部的events被保存在MemoryChannel中，Sink从MemoryChannel中读取数据； 当堆积在Channel中的events数大于阈值时， 全部的events被自动存放在FileChannel中，Sink从FileChannel中读取数据。这样当系统正常运行时，咱们可使用MemoryChannel的高吞吐特性；当系统有异常时，咱们能够利用FileChannel的大缓存的特性。

4.5 和scribe兼容

在设计之初，咱们就要求每类日志都有一个category相对应，而且Flume的Agent提供AvroSource和ScribeSource两种服务。这将保持和以前的Scribe相对应，减小业务的更改为本。

4.6 权限控制

在目前的日志收集系统中，咱们只使用最简单的权限控制。只有设定的category才能够进入到存储系统。因此目前的权限控制就是category过滤。

若是权限控制放在Agent端，优点是能够较好地控制垃圾数据在系统中流转。但劣势是配置修改麻烦，每增长一个日志就须要重启或者重载Agent的配置。

若是权限控制放在Collector端，优点是方便进行配置的修改和加载。劣势是部分没有注册的数据可能在Agent/Collector之间传输。

考虑到Agent/Collector之间的日志传输并不是系统瓶颈，且目前日志收集属内部系统，安全问题属于次要问题，因此选择采用Collector端控制。

4.7 提供实时流

美团的部分业务，如实时推荐，反爬虫服务等服务，须要处理实时的数据流。所以咱们但愿Flume可以导出一份实时流给Kafka/Storm系统。

一个很是重要的要求是实时数据流不该该受到其它Sink的速度影响，保证明时数据流的速度。这一点，咱们是经过Collector中设置不一样的Channel进行隔离，而且DualChannel的大容量保证了日志的处理不受Sink的影响。

5 系统监控

对于一个大型复杂系统来讲，监控是必不可少的部分。设计合理的监控，能够对异常状况及时发现，只要有一部手机，就能够知道系统是否正常运做。对于美团的日志收集系统，咱们创建了多维度的监控，防止未知的异常发生。

5.1 发送速度，拥堵状况，写Hdfs速度

经过发送给zabbix的数据，咱们能够绘制出发送数量、拥堵状况和写Hdfs速度的图表，对于超预期的拥堵，咱们会报警出来查找缘由。

下面是Flume Collector HdfsSink写数据到Hdfs的速度截图：

<ignore_js_op>  

下面是Flume Collector的FileChannel中拥堵的events数据量截图：

<ignore_js_op>  

5.2 flume写hfds状态的监控

Flume写入Hdfs会先生成tmp文件，对于特别重要的日志，咱们会每15分钟左右检查一下各个Collector是否都产生了tmp文件，对于没有正常产生tmp文件的Collector和日志咱们须要检查是否有异常。这样能够及时发现Flume和日志的异常.

5.3 日志大小异常监控

对于重要的日志，咱们会每一个小时都监控日志大小周同比是否有较大波动，并给予提醒，这个报警有效的发现了异常的日志，且屡次发现了应用方日志发送的异常，及时给予了对方反馈，帮助他们及早修复自身系统的异常。

经过上述的讲解，咱们能够看到，基于Flume的美团日志收集系统已是具有高可用性，高可靠性，可扩展等特性的分布式服务。

下一篇：
基于Flume的美团日志收集系统(二)改进和优化