共计 1716 个字符，预计需要花费 5 分钟才能阅读完成。
如何进行 Flume 的分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
一、什么是 Flume?
flume 作为 cloudera 开发的实时日志收集系统，受到了业界的认可与广泛应用。Flume 初始的发行版本目前被统称为 Flume OG（original generation），属于 cloudera。但随着 FLume 功能的扩展，Flume OG 代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点暴露出来，尤其是在 Flume OG 的最后一个发行版本 0.94.0 中，日志传输不稳定的现象尤为严重，为了解决这些问题，2011 年 10 月 22 号，cloudera 完成了 Flume-728，对 Flume 进行了里程碑式的改动：重构核心组件、核心配置以及代码架构，重构后的版本统称为 Flume NG（next generation）；改动的另一原因是将 Flume 纳入 apache 旗下，cloudera Flume 改名为 Apache Flume。
flume 的特点：
flume 是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据; 同时，Flume 提供对数据进行简单处理，并写到各种数据接受方 (比如文本、HDFS、Hbase 等) 的能力。
flume 的数据流由事件 (Event) 贯穿始终。事件是 Flume 的基本数据单位，它携带日志数据 (字节数组形式) 并且携带有头信息，这些 Event 由 Agent 外部的 Source 生成，当 Source 捕获事件后会进行特定的格式化，然后 Source 会把事件推入(单个或多个)Channel 中。你可以把 Channel 看作是一个缓冲区，它将保存事件直到 Sink 处理完该事件。Sink 负责持久化日志或者把事件推向另一个 Source。
flume 的可靠性
当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume 提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据 agent 首先将 event 写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是 scribe 采用的策略，当数据接收方 crash 时，将数据写到本地，待恢复后，继续发送），Besteffort（数据发送到接收方后，不会进行确认）。
flume 的可恢复性：
还是靠 Channel。推荐使用 FileChannel，事件持久化在本地文件系统里(性能较差)。
flume 的一些核心概念：
Agent 使用 JVM 运行 Flume。每台机器运行一个 agent，但是可以在一个 agent 中包含多个 sources 和 sinks。
Client 生产数据，运行在一个独立的线程。
Source 从 Client 收集数据，传递给 Channel。
Sink 从 Channel 收集数据，运行在一个独立线程。
Channel 连接 sources 和 sinks，这个有点像一个队列。
Events 可以是日志记录、avro 对象等。
Flume 以 agent 为最小的独立运行单位。一个 agent 就是一个 JVM。单 agent 由 Source、Sink 和 Channel 三大组件构成，如下图：
值得注意的是，Flume 提供了大量内置的 Source、Channel 和 Sink 类型。不同类型的 Source,Channel 和 Sink 可以自由组合。组合方式基于用户设置的配置文件，非常灵活。比如：Channel 可以把事件暂存在内存里，也可以持久化到本地硬盘上。Sink 可以把日志写入 HDFS, HBase，甚至是另外一个 Source 等等。Flume 支持用户建立多级流，也就是说，多个 agent 可以协同工作，并且支持 Fan-in、Fan-out、Contextual Routing、Backup Routes，这也正是 NB 之处。
看完上述内容，你们掌握如何进行 Flume 的分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
