基于Flume的美团日志收集系统.doc

1、1基于 Flume 的美团日志收集系统(一) 架构和设计 问题导读：1.Flume-NG 与 Scribe 对比，Flume-NG 的优势在什么地方？2.架构设计考虑 需要考虑什么 问题？3.Agent 死机该如何解决？4.Collector 死机是否会有影响？5.Flume-NG 可靠性(reliability)方面做了哪些措施？美团的日志收集系统负责美团的所有业务日志的收集，并分别给 Hadoop 平台提供离线数据和 Storm 平台提供实时数据流。美 团的日志收集系统基于 Flume 设计和搭建而成。基于 Flume 的美团日志收集系统将分两部分给读者呈现美团日志收集系统的架构设计和实战

2、经验。第一部分架构和设计，将主要着眼于日志收集系统整体的架构设计，以及为什么要做这样的设计。第二部分改进和优化，将主要着眼于实际部署和使用过程中遇到的问题，对 Flume 做的功能修改和优化等。1 日志收集系统简介日志收集是大数据的基石。许多公司的业务平台每天都会产生大量的日志数据。收集业务日志数据，供离线和在线的分析系统使用，正是日志收集系统的要做的事情。高可用性，高可靠性和可扩展性是日志收集系统所具有的基本特征。目前常用的开源日志收集系统有 Flume, Scribe 等。Flume 是 Cloudera 提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，目前已经是 A

3、pache 的一个子项目。Scribe 是 Facebook 开源的日志收集系统，它为日志的分布式收集，统一处理提供一个可扩展的，高容错的简单方案。2 常用的开源日志收集系统对比下面将对常见的开源日志收集系统 Flume 和 Scribe 的各方面 进行对比。对比中 Flume 将主要采用 Apache 下的 Flume-NG 为参考对象。同时，我们将常用的日志收集系统分为三层（Agent 层，Collector 层和 Store 层）来进行对比。对比项 Flume-NG Scribe使用语言 Java c/c+容错性Agent 和 Collector 间，Collector 和Store 间

4、都有容错性，且提供三种级别的可靠性保证；Agent 和 Collector 间, Collector 和Store 之间有容错性；负载均衡Agent 和 Collector 间，Collector 和Store 间有 LoadBalance 和 Failover 两种模式无可扩展性 好 好2Agent 丰富程度提供丰富的 Agent，包括 avro/thrift socket, text, tail 等 主要是 thrift 端口Store 丰富程度可以直接写 hdfs, text, console, tcp；写hdfs 时支持对 text 和 sequence 的压缩； 提供 buffer,

5、 network, file(hdfs, text)等代码结构 系统框架好，模块分明，易于开发 代码简单3 美团日志收集系 统架构美团的日志收集系统负责美团的所有业务日志的收集，并分别给 Hadoop 平台提供离线数据和 Storm 平台提供实时数据流。美 团的日志收集系统基于 Flume 设计和搭建而成。目前每天收集和处理约 T 级别的日志数据。下图是美团的日志收集系统的整体框架图。a. 整个系统分为三层：Agent 层，Collector 层和 Store 层。其中 Agent 层每个机器部署一个进程，负责对单机的日志收集工作；Collector 层部署在中心服务器上，负责接收 Agent

6、层发送的日志，并且将日志根据路由规则写到相应的 Store 层中；Store 层负责提供永久或者临时的日志存储服务，或者将日志流导向其它服务器。b. Agent 到 Collector 使用 LoadBalance 策略，将所有的日志均衡地发到所有的 Collector上，达到负载均衡的目标，同时并处理单个 Collector 失效的问题。c. Collector 层 的目标主要有三个： SinkHdfs, SinkKafka 和 SinkBypass。分别提供离线的数据到 Hdfs，和提供 实时的日志流到 Kafka 和 Bypass。其中 SinkHdfs 又根据日志量的大小分为 Sink

7、Hdfs_b，SinkHdfs_m 和 SinkHdfs_s 三个 Sink，以提高写入到 Hdfs 的性能，具体见后面介绍。d. 对于 Store 来说，Hdfs 负责 永久地存储所有日志；Kafka 存储最新的 7 天日志，并给Storm 系统提供实时日志流； Bypass 负责给其它服务器和 应用提供实时日志流。3下图是美团的日志收集系统的模块分解图，详解 Agent, Collector 和 Bypass 中的 Source, Channel 和 Sink 的关系。a. 模 块 命名规则：所有的 Source 以 src 开头，所有的 Channel 以 ch 开头，所有的 Sink以

8、 sink 开头；b. Channel 统一使用美团开发 的 DualChannel，具体原因后面详述；对于过滤掉的日志使用 NullChannel，具体原因后面 详述；c. 模块 之间内部通信统一使用 Avro 接口；4 架构设计考 虑下面将从可用性，可靠性，可扩展性和兼容性等方面，对上述的架构做细致的解析。4.1 可用性(availablity)对日志收集系统来说，可用性(availablity)指固定周期内系 统无故障运行总时间。要想提高系统的可用性，就需要消除系统的单点，提高系统的冗余度。下面来看看美团的日志收集系统在可用性方面的考虑。4.1.1 Agent 死掉Agent 死掉分为两

9、种情况：机器死机或者 Agent 进程死掉。对于机器死机的情况来说，由于产生日志的进程也同样会死掉，所以不会再产生新的日志，不存在不提供服务的情况。对于 Agent 进程死掉的情况来说，确实会降低系统的可用性。 对此，我们有下面三种方式来提高系统的可用性。首先，所有的 Agent 在 supervise 的方式下启动，如果进程死掉会被系统立即重启，以提供服务。其次，对所有的 Agent 进 行存活监控，发现 Agent 死掉立即报警。最后，对于非常重要的日志，建议应用直接将日志写磁盘，Agent 使用 spooldir的方式获得最新的日志。4.1.2 Collector 死掉由于中心服务器提供

10、的是对等的且无差别的服务，且 Agent 访问 Collector 做了4LoadBalance 和重试机制。所以当某个 Collector 无法提供服务时，Agent 的重试策略会将数据发送到其它可用的 Collector 上面。所以整个服务不受影响。4.1.3 Hdfs 正常停机我们在 Collector 的 HdfsSink 中提供了开关选项，可以控制 Collector 停止写 Hdfs，并且将所有的 events 缓存到 FileChannel 的功能。4.1.4 Hdfs 异常停机或不可访问假如 Hdfs 异常停机或不可 访问，此时 Collector 无法写 Hdfs。由于我们使

11、用DualChannel，Collector 可以将所收到的 events 缓存到 FileChannel，保存在磁盘上，继续提供服务。当 Hdfs 恢复服务以后，再将 FileChannel 中缓 存的 events 再发送到 Hdfs 上。这种机制类似于 Scribe，可以提供 较好的容错性。4.1.5 Collector 变慢或者 Agent/Collector 网络变慢如果 Collector 处理速度变慢（比如机器 load 过高）或者 Agent/Collector 之间的网络变慢，可能导致 Agent 发送到 Collector 的速度变慢。同样的，对于此种情况，我们在 Agen

12、t 端使用 DualChannel，Agent 可以将收到的 events 缓存到 FileChannel，保存在磁盘上，继续提供服务。当 Collector 恢复服务以后，再将 FileChannel 中缓存的 events 再发送给Collector。4.1.6 Hdfs 变慢当 Hadoop 上的任务较多且有大量的读写操作时，Hdfs 的读写数据往往变的很慢。由于每天，每周都有高峰使用期，所以这种情况非常普遍。对于 Hdfs 变慢的 问题，我们同样使用 DualChannel 来解决。当 Hdfs 写入较快时，所有的events 只经过 MemChannel 传递数据，减少磁盘 IO，获

13、得较高性能。当 Hdfs 写入较慢时，所有的 events 只经过 FileChannel 传递数据，有一个较大的数据 缓存空间。4.2 可靠性(reliability)对日志收集系统来说，可靠性(reliability)是指 Flume 在数据流的传输过程中，保证 events的可靠传递。对 Flume 来说，所有的 events 都被保存在 Agent 的 Channel 中，然后被发送到数据流中的下一个 Agent 或者最终的存储服务中。那么一个 Agent 的 Channel 中的 events 什么时候被删除呢？当且仅当它们被保存到下一个 Agent 的 Channel 中或者被保存

14、到最终的存储服务中。这就是 Flume 提供数据流中点到点的可靠性保证的最基本的单跳消息传递语义。那么 Flume 是如何做到上述最基本的消息传递语义呢？首先，Agent 间的事务交换。Flume 使用事务的办法来保证 event 的可靠传递。Source 和Sink 分别被封装在事务中，这些事务由保存 event 的存储提供或者由 Channel 提供。这就保证了 event 在数据流的点对点传输中是可靠的。在多级数据流中，如下图，上一级的Sink 和下一级的 Source 都被包含在事务中，保证数据可靠地从一个 Channel 到另一个Channel 转移。5其次，数据流中 Channel

15、 的持久性。 Flume 中 MemoryChannel 是可能丢失数据的（当Agent 死掉时），而 FileChannel 是持久性的，提供类似 mysql 的日志机制，保证数据不丢失。4.3 可扩展性(scalability)对日志收集系统来说，可扩展性(scalability)是指系统能够线性扩展。当日志量增大时，系统能够以简单的增加机器来达到线性扩容的目的。对于基于 Flume 的日志收集系统来说，需要在设计的每一层，都可以做到线性扩展地提供服务。下面将对每一层的可扩展性做相应的说明。4.3.1 Agent 层对于 Agent 这一层来说，每个机器部署一个 Agent，可以水平扩展，

16、不受限制。一个方面，Agent 收集日志的能力受限于机器的性能，正常情况下一个 Agent 可以为单机提供足够服务。另一方面，如果机器比较多，可能受限于后端 Collector 提供的服务，但 Agent 到Collector 是有 Load Balance 机制，使得 Collector 可以线 性扩展提高能力。4.3.2 Collector 层对于 Collector 这一层，Agent 到 Collector 是有 Load Balance 机制，并且 Collector 提供无差别服务，所以可以线性扩展。其性能主要受限于 Store 层提供的能力。4.3.3 Store 层对于 Sto

17、re 这一层来说，Hdfs 和 Kafka 都是分布式系统，可以做到线性扩展。Bypass 属于临时的应用，只对应于某一类日志，性能不是瓶颈。4.4 Channel 的选择Flume1.4.0 中，其官方提供常用的 MemoryChannel 和 FileChannel 供大家选择。其优劣如下： MemoryChannel: 所有的 events 被保存在内存中。优 点是高吞吐。缺点是容量有限并且 Agent 死掉时会丢失内存中的数据。 FileChannel: 所有的 events 被保存在文件中。优点是容量 较大且死掉时数据可恢复。缺点是速度较慢。上述两种 Channel，优缺点相反，分

18、别有自己适合的场景。然而， 对于大部分应用来说，我们希望 Channel 可以同提供高吞吐和大 缓存。基于此，我 们开发了 DualChannel。 DualChannel：基于 MemoryChannel 和 FileChannel 开发。当堆积在 Channel 中的events 数小于阈值时，所有的 events 被保存在 MemoryChannel 中，Sink 从MemoryChannel 中读取数据； 当堆积在 Channel 中的 events 数大于阈值时， 所有的 events 被自动存放在 FileChannel 中，Sink 从 FileChannel 中读取数据。这样当

19、系统正常运行时，我们可以使用 MemoryChannel 的高吞吐特性；当系 统有异常时，我们可以利用 FileChannel 的大缓存的特性。4.5 和 scribe 兼容在设计之初，我们就要求每类日志都有一个 category 相对应，并且 Flume 的 Agent 提供AvroSource 和 ScribeSource 两种服务。这将保持和之前的 Scribe 相对应，减少业务的更改成本。4.6 权限控制在目前的日志收集系统中，我们只使用最简单的权限控制。只有设定的 category 才可以进入到存储系统。所以目前的权限控制就是 category 过滤。如果权限控制放在 Agent 端

20、，优势是可以较好地控制垃圾数据在系 统中流转。但劣势是配置修改麻烦，每增加一个日志就需要重启或者重载 Agent 的配置。6如果权限控制放在 Collector 端，优势是方便进行配置的修改和加载。劣势是部分没有注册的数据可能在 Agent/Collector 之间传输。考虑到 Agent/Collector 之间的日志传输并非系统瓶颈，且目前日志收集属内部系 统，安全问题属于次要问题，所以选择采用 Collector 端控制。4.7 提供实时流美团的部分业务，如实时推荐，反爬虫服务等服务，需要处理实时的数据流。因此我们希望 Flume 能够导出一份实时流给 Kafka/Storm 系统。一个

21、非常重要的要求是实时数据流不应该受到其它 Sink 的速度影响，保 证实时数据流的速度。这一点，我们是通过 Collector 中设置不同的 Channel 进行隔离，并且 DualChannel 的大容量保证了日志的处理不受 Sink 的影响。5 系统监控对于一个大型复杂系统来说，监控是必不可少的部分。设计合理的监控，可以对异常情况及时发现，只要有一部手机，就可以知道系统是否正常运作。对于美团的日志收集系统，我们建立了多维度的监控，防止未知的异常发生。5.1 发送速度，拥堵情况，写 Hdfs 速度通过发送给 zabbix 的数据，我们可以绘制出发送数量、拥堵情况和写 Hdfs 速度的图表，对

22、于超预期的拥堵，我们会报警出来查找原因。下面是 Flume Collector HdfsSink 写数据到 Hdfs 的速度截图：下面是 Flume Collector 的 FileChannel 中拥堵的 events 数据量截图：75.2 flume 写 hfds 状态的监 控Flume 写入 Hdfs 会先生成 tmp 文件，对于特别重要的日志，我 们会每 15 分钟左右检查一下各个 Collector 是否都产生了 tmp 文件，对于没有正常 产生 tmp 文件的 Collector 和日志我们需要检查是否有异常。这样可以及时发现 Flume 和日志的异常.5.3 日志大小异常监控对于

23、重要的日志，我们会每个小时都监控日志大小周同比是否有较大波动，并给予提醒，这个报警有效的发现了异常的日志，且多次发现了应用方日志发送的异常，及时给予了对方反馈，帮助他们及早修复自身系统的异常。通过上述的讲解，我们可以看到，基于 Flume 的美团日志收集系统已经是具备高可用性，高可靠性，可扩展等特性的分布式服务。基于 Flume 的美团日志收集系统(二) 改进和优化问题导读：1.Flume 的存在些什么问题？2.基于开源的 Flume 美团增加了哪些功能？3.Flume 系统如何调优？在 基于 Flume 的美团日志收集系统(一)架构和设计中，我们详述了基于 Flume 的美团日志收集系统的架

24、构设计，以及为什么做这样的设计。在本节中，我们将会讲述在实际部署和使用过程中遇到的问题，对 Flume 的功能改进和对系统做的优化。1 Flume 的问题总结在 Flume 的使用过程中，遇到的主要问题如下：a. Channel“水土不服”：使用固定大小的 MemoryChannel 在日志高峰时常报队列大小不够的异常；使用 FileChannel 又导致 IO 繁忙的问题；b. HdfsSink 的性能 问题：使用 HdfsSink 向 Hdfs 写日志，在高峰时间速度较慢；c. 系统 的管理问题：配置升级，模块重启等；2 Flume 的功能改进和优化点8从上面的问题中可以看到，有一些需求是

25、原生 Flume 无法满足的，因此，基于开源的Flume 我们增加了许多功能，修改了一些 Bug，并且进行一些调优。下面将对一些主要的方面做一些说明。2.1 增加 Zabbix monitor 服务一方面，Flume 本身提供了 http, ganglia 的监控服务，而我们目前主要使用 zabbix 做监控。因此，我们为 Flume 添加了 zabbix 监控模块，和 sa 的监控服务无缝融合。另一方面，净化 Flume 的 metrics。只将我们需要的 metrics 发送给 zabbix，避免 zabbix server 造成 压力。目前我们最为关心的是 Flume 能否及时把应用端发

26、送过来的日志写到Hdfs 上， 对应 关注的 metrics 为： Source : 接收的 event 数和处理的 event 数 Channel : Channel 中拥 堵的 event 数 Sink : 已 经处理的 event 数2.2 为 HdfsSink 增加自动创建 index 功能首先，我们的 HdfsSink 写到 hadoop 的文件采用 lzo 压缩存储。 HdfsSink 可以读取hadoop 配置文件中提供的编码类列表，然后通过配置的方式获取使用何种压缩编码，我们目前使用 lzo 压缩数据。采用 lzo 压缩而非 bz2 压缩，是基于以下测试数据：event 大小(

27、Byte) sink.batch-size hdfs.batchSize压缩格式总数据大小(G)耗时(s)平均events/s压缩后大小(G)544 300 10000 bz2 9.1 2448 6833 1.36544 300 10000 lzo 9.1 612 27333 3.49其次，我们的 HdfsSink 增加了创建 lzo 文件后自动创建 index 功能。Hadoop 提供了对 lzo创建索引，使得压缩文件是可切分的，这样 Hadoop Job 可以并行处理数据文件。HdfsSink本身 lzo 压缩，但写完 lzo 文件并不会建索引，我们在 close 文件之后添加了建索引功能

28、。/* Rename bucketPath file from .tmp to permanent location.*/private void renameBucket() throws IOException, InterruptedException if(bucketPath.equals(targetPath) return;final Path srcPath = new Path(bucketPath);final Path dstPath = new Path(targetPath);callWithTimeout(new CallRunner() Overridepubli

29、c Object call() throws Exception if(fileSystem.exists(srcPath) / could blockLOG.info(“Renaming “ + srcPath + “ to “ + dstPath);fileSystem.rename(srcPath, dstPath); / could block9/index the dstPath lzo fileif (codeC != null lzoIndexer.index(dstPath);return null;);2.3 增加 HdfsSink 的开关我们在 HdfsSink 和 Dua

30、lChannel 中增加开关，当开关打开的情况下，HdfsSink 不再往Hdfs 上写数据，并且数据只写向 DualChannel 中的 FileChannel。以此策略来防止 Hdfs 的正常停机维护。2.4 增加 DualChannelFlume 本身提供了 MemoryChannel 和 FileChannel。MemoryChannel 处理速度快，但缓存大小有限，且没有持久化；FileChannel 则刚好相反。我们希望利用两者的优势，在 Sink处理速度够快，Channel 没有 缓存过多日志的时候，就使用 MemoryChannel，当 Sink 处理速度跟不上，又需要 Cha

31、nnel 能够缓存下应用端发送过来的日志 时，就使用 FileChannel，由此我们开发了 DualChannel，能够智能的在两个 Channel 之间切换。其具体的逻辑如下：/* putToMemChannel indicate put event to memChannel or fileChannel* takeFromMemChannel indicate take event from memChannel or fileChannel* */private AtomicBoolean putToMemChannel = new AtomicBoolean(true);priva

32、te AtomicBoolean takeFromMemChannel = new AtomicBoolean(true);void doPut(Event event) if (switchon if ( memChannel.isFull() | fileChannel.getQueueSize() 100) putToMemChannel.set(false); else /往 fileChannel 中写数据fileTransaction.put(event);10Event doTake() Event event = null;if ( takeFromMemChannel.get

33、() ) /从 memChannel 中取数据event = memTransaction.take();if (event = null) takeFromMemChannel.set(false); else /从 fileChannel 中取数据event = fileTransaction.take();if (event = null) takeFromMemChannel.set(true);putToMemChannel.set(true); return event;2.5 增加 NullChannelFlume 提供了 NullSink，可以把不需要的日志通过 NullSin

34、k 直接丢弃，不进行存储。然而，Source 需要先将 events 存放到 Channel 中，NullSink 再将 events 取出扔掉。为了提升性能，我们把这一步移到了 Channel 里面做，所以开发了 NullChannel。2.6 增加 KafkaSink为支持向 Storm 提供实时数据流，我 们增加了 KafkaSink 用来向 Kafka 写实时数据流。其基本的逻辑如下：public class KafkaSink extends AbstractSink implements Configurable private String zkConnect;private I

35、nteger zkTimeout;private Integer batchSize;private Integer queueSize;private String serializerClass;private String producerType;private String topicPrefix;private Producer producer;public void configure(Context context) /读取配置，并 检查配置Override11public synchronized void start() /初始化 producerOverridepubl

36、ic synchronized void stop() /关闭 producerOverridepublic Status process() throws EventDeliveryException Status status = Status.READY;Channel channel = getChannel();Transaction tx = channel.getTransaction();try tx.begin();/将日志按 category 分队列存放Map topic2EventList = new HashMap();/从 channel 中取 batchSize 大

37、小的日志，从 header 中获取category，生成 topic，并存放于上述的 Map 中；/将 Map 中的数据通过 producer 发送给 kafka mit(); catch (Exception e) tx.rollback();throw new EventDeliveryException(e); finally tx.close();return status;2.7 修复和 scribe 的兼容问题Scribed 在通过 ScribeSource 发送数据包给 Flume 时，大于 4096 字节的包，会先发送一个 Dummy 包检查服务器的反应，而 Flume 的 S

38、cribeSource 对于 logentry.size()=0 的包返回 TRY_LATER，此时 Scribed 就认为出错，断开连接。这样循环反复尝试，无法真正发送12数据。现在在 ScribeSource 的 Thrift 接口中，对 size 为 0 的情况返回 OK，保证后续正常发送数据。3. Flume 系统调优经验总结 3.1 基础参数调优经验 HdfsSink 中默认的 serializer 会每写一行在行尾添加一个换行符，我们日志本身带有换行符，这样会导致每条日志后面多一个空行，修改配置不要自动添加换行符；lc.sinks.sink_hdfs.serializer.appe

39、ndNewline = false 调大 MemoryChannel 的 capacity，尽量利用 MemoryChannel 快速的处理能力； 调大 HdfsSink 的 batchSize，增加吞吐量，减少 hdfs 的 flush 次数； 适当调大 HdfsSink 的 callTimeout，避免不必要的超时错误；3.2 HdfsSink 获取 Filename 的优化HdfsSink 的 path 参数指明了日志被写到 Hdfs 的位置，该参数中可以引用格式化的参数，将日志写到一个动态的目录中。这方便了日志的管理。例如我们可以将日志写到 category分类的目录，并且按天和按小时

40、存放：lc.sinks.sink_hdfs.hdfs.path = /user/hive/work/orglog.db/%category/dt=%Y%m%d/hour=%HHdfsS ink 中处 理每条 event 时，都要根据配置获取此 event 应该写入的 Hdfs path 和filename，默认 的获取方法是通过正则表达式替换配置中的变量，获取真实的 path 和filename。因为 此过程是每条 event 都要做的操作，耗时很长。通过我们的测试，20 万条日志，这个操作要耗时 6-8s 左右。由于我们目前的 path 和 filename 有固定的模式，可以通过字符串拼接

41、获得。而后者比正则匹配快几十倍。拼接定符串的方式，20 万条日志的操作只需要几百毫秒。3.3 HdfsSink 的 b/m/s 优 化在我们初始的设计中，所有的日志都通过一个 Channel 和一个 HdfsSink 写到 Hdfs 上。我们来看一看这样做有什么问题。首先，我们来看一下 HdfsSink 在发送数据的逻辑：/从 Channel 中取 batchSize 大小的 eventsfor (txnEventCount = 0; txnEventCount batchSize; txnEventCount+) /对每条日志根据 category append 到相应的 bucketWri

42、ter 上；bucketWriter.append(event);for (BucketWriter bucketWriter : writers) /然后对每一个 bucketWriter 调用相应的 flush 方法将数据 flush 到 Hdfs 上bucketWriter.flush();假设我们的系统中有 100 个 category，batchSize 大小设置为 20 万。则每 20 万条数据，就需要对 100 个文件进行 append 或者 flush 操作。其次，对于我们的日志来说，基本符合 80/20 原则。即 20%的 category 产生了系统 80%的日志量。这样对大部分日志来说，每 20 万条可能只包含几条日志，也需要往 Hdfs 上flush 一次。13上述的情况会导致 HdfsSink 写 Hdfs 的效率极差。下图是单 Channel 的情况下每小时的发送量和写 hdfs 的时间趋势图。鉴于这种实际应用场景，我们把日志进行了大小归类，分为 big, middle 和 small 三类，这样可以有效的避免小日志跟着大日志一起频繁的 flush，提升效果明显。下图是分队列后big 队列的每小时的发送量和写 hdfs 的时间趋势图。