Meituan log collection system based on Flume (1)

【转：】http://blog.csdn.net/qq405371160/article/details/41696269

Meituan's log collection system is responsible for the collection of all business logs of Meituan, and provides offline data to the Hadoop platform and real-time data streams to the Storm platform. Meituan's log collection system is designed and built based on Flume.

"Meituan Log Collection System Based on Flume" will present the architecture design and practical experience of the Meituan log collection system to readers in two parts .

The first part of architecture and design will mainly focus on the overall architecture design of the log collection system and why it is designed.

The second part of improvement and optimization will mainly focus on the problems encountered in the actual deployment and use process, and the functional modification and optimization of Flume.

1 Introduction to the log collection system

Log collection is the cornerstone of big data .

The business platforms of many companies generate large amounts of log data every day. Collecting business log data for offline and online analysis systems is exactly what the log collection system does. High availability, high reliability and scalability are the basic characteristics of a log collection system.

Currently commonly used open source log collection systems include Flume, Scribe, etc. Flume is a highly available, highly reliable, distributed massive log collection, aggregation and transmission system provided by Cloudera. It is currently a sub-project of Apache. Scribe is Facebook's open source log collection system, which provides a scalable, highly fault-tolerant simple solution for distributed collection and unified processing of logs.

2 Comparison of common open source log collection systems

The following will compare various aspects of the common open source log collection systems Flume and Scribe. In the comparison, Flume will mainly use Flume-NG under Apache as the reference object. At the same time, we divide the commonly used log collection system into three layers (Agent layer, Collector layer and Store layer) for comparison.

Contrast Term Flume-NG Scribe

language used	Java	c/c++
fault tolerance	There is fault tolerance between the Agent and the Collector, and between the Collector and the Store, and provides three levels of reliability guarantees;	There is fault tolerance between Agent and Collector, and between Collector and Store;
load balancing	There are two modes of LoadBalance and Failover between Agent and Collector, and between Collector and Store	without
Scalability	Okay	Okay
Agent richness	Provide rich agents, including avro/thrift socket, text, tail, etc.	Mainly thrift ports
Store richness	Can write hdfs, text, console, tcp directly; support compression of text and sequence when writing hdfs;	Provide buffer, network, file (hdfs, text), etc.
code structure	The system framework is good, the modules are clear, and it is easy to develop	simple code

3 Meituan log collection system architecture

The following figure is the overall framework diagram of Meituan's log collection system.

Meituan log collection system architecture

a. The whole system is divided into three layers: Agent layer, Collector layer and Store layer. The Agent layer deploys one process per machine, which is responsible for collecting logs of a single machine; the Collector layer is deployed on the central server, responsible for receiving the logs sent by the Agent layer, and writing the logs to the corresponding Store layer according to the routing rules; Store layer Responsible for providing permanent or temporary log storage services, or directing log streams to other servers.

b. The Agent to the Collector uses the LoadBalance strategy to send all logs to all the Collectors in a balanced manner to achieve the goal of load balancing and to deal with the failure of a single 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的关系。

Meituan log collection system architecture

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转移。

Meituan log collection system architecture

其次，数据流中 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的速度截图：

Meituan log collection system architecture

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

Meituan log collection system architecture

5.2 flume写hfds状态的监控

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

5.3 日志大小异常监控

For important logs, we will monitor whether the log size fluctuates significantly year-on-year every hour, and give reminders. This alarm effectively detects abnormal logs, and finds abnormal log sending by the application side for many times. Get feedback from the other party and help them repair their own system anomalies as soon as possible.

Through the above explanation, we can see that the Flume-based Meituan log collection system is already a distributed service with features such as high availability, high reliability, and scalability.