分布式日志收集工具分析比较

目录

写在最前：为什么做日志收集系统❓

一、多种日志收集工具比较

1、背景介绍

2、Facebook 的 Scribe

3、Apache 的 Chukwa

4、LinkedIn 的 Kafka

5、Cloudera 的 Flume OG

6、“星星”小结

7、众星捧月之 Apache 的 Flume NG

Flume NG 架构：

Flume NG 特性：

Flume NG 节点组成图：

Flume NG 常用组件

删减节点角色，脱离 zookeeper

用户配置变化之安装

用户配置变化之数据传输配置

结束语

二、分布式日志收集框架 Flume NG

写在最前：为什么做日志收集系统❓
首先，什么是日志？日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据。

通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、应用日志、安全日志。这些日志分散地存储在不同的机器上。

当系统发生故障时，工程师就需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件或日志文件达到某给定大小后生成一个文件），还有日志压缩归档策略等。

这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提供高诊断效率，同时对系统情况有个全面的理解，避免事后救火的被动。

个人认为，日志数据在以下几个方面具有非常重要的作用：

数据查找：通过检索日志信息，定位相应的 bug，找出解决方案；
服务诊断：通过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态；
数据分析：可以做进一步的数据分析。
一、多种日志收集工具比较
1、背景介绍
许多公司的平台每天会产生大量的日志（一般为流式数据，如搜索引擎 pv、uv，查询等），处理这些日志需要特定的日至系统，一般而言，这些系统需要具备以下特征：

构建应用系统和分析系统的桥梁，并将它们之间的关联解耦合；
支持近时时的在线分析系统和类似于 Hadoop 之类的离线分析系统；
具有高可扩展性。即：当数据量增加时，可以通过增加节点进行水平扩展。
👇下面将从设计架构、负载均衡、可扩展性和容错性等方面对比当今开源的日志系统，包括 Facebook 的 scribe，Apache 的 chukwa，LinkedIn 的 kafka 和 Cloudera 的 flume 等。

2、Facebook 的 Scribe
scribe 主页：https://github.com/facebook/scribe

scribe 是 Facebook 开源的日志收集系统，在 Facebook 内部已经得到大量的应用。它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是 NFS，分布式文件系统等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供了一个可扩展的、高容错的方案。

它最重要的特点是容错性好。当后端的存储系统 crash 时，scribe 会将数据写到本地磁盘上，当存储系统恢复正常后，scribe 将日志重新加载到存储系统中。

架构：

scribe 的架构比较简单，主要包括三部分，分别为 scribe agent，scribe 和存储系统。

（1）scribe agent

scribe agent 实际上是一个 thrift client。向 scribe 发送数据的唯一方法是使用 thrift client，scribe 内部定义了一个 thrift 接口，用户使用该接口将数据发送给 server。

（2）scribe

scribe 接收到 thrift client 发送过来的数据，根据配置文件，将不同 topic 的数据发送给不同的对象。scribe 提供了各种各样的 store，如 file、HDFS 等，scribe 可将数据加载到这些 store 中。

（3）存储系统

存储系统实际上就是 scribe 中的 store，当前 scribe 支持非常多的 store，包括 file（文件），buffer（双层存储，一个主存储，一个副存储），network（另一个 scribe 服务器），bucket（包含多个 store，通过 hash 将数据存到不同 store 中），null（忽略数据），thriftfile（写到一个 Thrift TFileTransport 文件中）和 multi（把数据同时存放到不同 store 中）。

3、Apache 的 Chukwa
chukwa 主页：http://incubator.apache.org/chukwa/

chukwa 是一个非常新的开源项目，由于其属于 hadoop 系列产品，因而使用了很多 hadoop 的组件（用 HDFS 存储，用 MapReduce 处理数据），它提供了很多模块以支持 hadoop 集群日志分析。

需求：

灵活性，动态可控的数据源
高性能，高可扩展的存储系统
合适的架构，用于对收集到的大规模数据进行分析
架构：

Chukwa 中主要有 3 个角色，分别是 adaptor，agent，collector。

（1）Adaptor 数据源

可封装其它数据源，如 file，Unix 命令行工具等。

目前可用的数据源有：hadoop logs，应用程序度量数据，系统参数数据（如 Linux CPU 使用率等）

（2）HDFS 存储系统

Chukwa 采用了 HDFS 作为存储系统。HDFS 的设计初衷是支持大文件和小并发高速写的应用场景，而日志系统的特点恰好相反，它需要支持高并发低速率的写和大量小文件的存储。需要注意的是，直接写到 HDFS 上的小文件是不可见的，直到关闭文件，另外 HDFS 不支持文件重新打开。

（3）Collector 和 Agent

为了克服（2）中的问题，增加了 agent 和 collector 阶段。

agent 的作用：给 adaptor 提供各种服务，包括：启动和关闭 adaptor，将数据通过 HTTP 传递给 collector；定期记录 adaptor 状态，以便 crash 后恢复。

collector 的作用：对多个数据源发过来的数据进行合并，然后加载到 HDFS 中；隐藏 HDFS 实现的细节，如：HDFS 版本更换后，只需要修改 collector 即可。

（4）Demux 和 achieving

直接支持利用 MapReduce 处理数据。它内置了两个 MapReduce 作业，分别用于获取 data 和将 data 转化为结构化的 log。存储到 data store（可以是数据库或者 HDFS 等）中。

4、LinkedIn 的 Kafka
kafka 主页：http://kafka.apache.org

kafka 是 2010 年 12 月份开源的项目，采用 Scala 语言编写，使用了多种效率优先机制，整体架构比较新颖（push / pull），更适合异构集群。

设计目标：

数据在磁盘上存取代价为 0（1）
高吞吐率，在普通的服务器上每秒也能处理几十万条消息
分布式架构，能够对消息分区
支持将数据并行的加载到 hadoop
架构：

kafka 实际上是一个消息发布订阅系统。producer 向某个 topic 发布消息，而 consumer 订阅某个 topic 消息，进而一旦有新的关于某个 topic 的消息，broker 会传递给订阅它的所有 consumer。在 kafka 中，消息是按 topic 组织的，而每个 topic 又会分为多个 partition，这样便于管理数据和进行负载均衡。同时，它也使用了 zookeeper 进行负载均衡。

kafka 中主要有三个角色：分别为 producer、broker 和consumer。

（1）producer

producer 的任务是向 broker 发送数据。kafka 提供了两种 producer 接口，一种是 low_level 接口，使用该接口会向指定的 broker 的某个 topic 下的某个 partition 发送数据。另一种是 high_level 接口，该接口支持同步/异步发送数据，基于 zookeeper 的 broker 自动识别和负载均衡（基于 Partitioner）。

其中，基于 zookeeper 的 broker 自动识别值得说一说。producer 可以通过 zookeeper 获取可用的 broker列表，也可以在 zookeeper 中注册 listener，该 listener 在以下情况下会被唤醒：

添加一个 broker
删除一个 broker
注册新的 topic
broker 注册已存在的 topic
当 producer 得知以上事件时，可以根据需要采取一定行动。

（2）broker

broker 采取多种策略提高数据处理效率，包括 sendfile 和 zero copy 等技术。

（3）consumer

consumer 的作用是将日志信息加载到中央存储系统上。kafka 提供了两种 consumer 接口，一种是 low_level 接口，它维护到某一个 broker 连接，并且这个连接是无状态的，即，每次从 broker 上 push 数据时，都要告诉 broker 数据的偏移量。另一种是 high_level 接口，它隐藏了 broker的细节，运行 consumer 从 broker 上 push 数据而不必关系网络拓扑结构。更重要的是，对于大部分日志系统而言，consumer 已经获取的数据信息都由 broker 保存，而 kafka 中，由 consumer 自己维护所取数据信息。

5、Cloudera 的 Flume OG
flume-og 主页：https://github.com/cloudera/flume/

Flume OG 是 Cloudera 于 2009 年 7 月开源的日志系统。它内置的各种组件非常齐全，用户几乎不必进行任何额外的开发即可使用。

设计目标：

（1）可靠性

当节点出现故障时，日志能够被传送到其它节点上而不会丢失。flume-og 提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据 agent 首先将 event 写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送），store-on-failure（这也是 scribe 采用的策略，当数据接收方 crash 时，将数据写到本地，待恢复后，继续发送），best-effort（数据发送到接收方后，不会进行确认）。

（2）可扩展性

flume-og 采用三层架构，分别为 agent，collector 和 storage，每一层均可以水平扩展。其中，所有 agent 和 collector 由 master 统一管理，这使得系统容易监控和维护，且 master 允许有多个（使用 zookeeper 进行管理和负载均衡），这就避免了单点故障问题。

（3）可管理性

所有 agent 和 collector 由 master 统一管理，这使得系统便于维护。用户可以在 master 上查看各个数据源或者数据流执行情况，且可以对各个数据源配置和动态加载。flume-og 提供了 web 和 shell script command 两种形式对数据流进行管理。

（4）功能可扩展性

用户可以更具需要添加自己的 agent，collector 或者 storage。此外，flume 自带了很多组件，包括各种 agent（file，syslog 等），collector 和 storage（file，HDFS 等）。

Flume OG 架构：

FLUM OG 有三种角色的节点：代理节点（agent）、收集节点（collector）、主节点（master）。

agent 从各个数据源收集日志数据，将收集到的数据集中到 collector，然后由收集节点汇总存入 hdfs。master 负责管理 agent，collector 的活动。
agent、collector 都称为 node，node 的角色根据配置的不同分为 logical node（逻辑节点）、physical node（物理节点）。对 logical nodes 和 physical nodes 的区分、配置、使用一直以来都是使用者最头疼的地方。
agent、collector 由 source、sink 组成，代表在当前节点数据是从 source 传送到 sink。
 

正如上面提到的，flume-og 采用了分层架构，由三层组成，分别为 agent，collector 和 storage。其中，agent 和 collector 均由两部分组成：source 和 sink，source 是数据来源，sink 是数据去向。

（1）agent

agent 的作用是将数据源的数据发送给 collector，flume-og 自带了很多直接可用的数据源（source），如：

text("filename")：将文件 filename 作为数据源，按行发送
tail("filename")：探测 filename 新产生的数据，按行发送出去
fsyslogTcp(5140)：监听 TCP 的 5140 端口，并且接收到的数据发送出去
同时提供了很多 sink，如：

console[("format)]：直接将数据显示在桌面上
text("txtfile")：将数据写到文件 txtfile 中
dfs("dfsfile")：将数据写到 HDFS 上的 dfsfile 文件中
syslogTcp("host",port)：将数据通过 TCP 传递给 host 节点
（2）collector

collector 的作用是将多个 agent 的数据汇总后，加载到 storage 中。它的 source 和 sink 与 agent 类似。

（3）storage

storage 是存储系统，可以是一个普通 file，也可以是 HDFS，HIVE，HBASE 等。

6、“星星”小结
根据这四个系统的架构设计，可以总结出典型的日至系统需具备三个基本组件，分别为 agent（封装数据源，将数据源中的数据发送给 collector），collector（接收多个 agent 的数据，并进行汇总后导入后端的 store 中），store（中央存储系统，应该具有可扩展性和可靠性，应该支持当前非常流行的 HDFS）。

下面👇对比了这四个系统：

7、众星捧月之 Apache 的 Flume NG
flume-ng 官网地址：http://flume.apache.org
用户文档：http://flume.apache.org/FlumeUserGuide.html
开发文档： http://flume.apache.org/FlumeDeveloperGuide.html
 

NG 只有一种角色的节点：代理节点（agent）：

没有 collector、master 节点。这是核心组件最核心的变化。
去除了 physical nodes、logical nodes 的概念和相关内容。
agent 节点的组成也发生了变化。NG agent 由 source、sink、channel 组成。
Flume NG 架构：

 

Flume NG 特性：
Flume NG 是一个分布式、可靠、高可用的海量日志聚合系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume NG 提供对数据进行简单处理，并写到各种数据接收方。

（1）高可靠性：Flume NG 提供了end to end的数据可靠性机制；

（2）易于扩展：Agent 为分布式架构，可水平扩展；

（3）易于恢复：Channel 中保存了与数据源有关的事件，用于失败时的恢复；

（4）功能丰富：Flume NG 内置了多种组件，包括不同数据源和不同存储方式；

Flume NG 节点组成图：

 

Flume NG 常用组件
（1）Source：数据源，简单的说就是 agent 获取数据的入口；

（2）Channel：管道，数据流通和存储的通道。一个 source 必须至少和一个 channel 关联；

（3）Sink：用来接收 channel 传输的数据并将之传送到指定的地方，成功后从 channel 中删除；

从整体上讲，NG 在核心组件上进行了大规模的调整，核心组件的数目由 7 删减到 4。由于 Flume 的使用涉及到众多因素，如 avro、thrift、hdfs、jdbc、zookeeper 等，而这些组件和 Flume 的整合都需要关联到所有组件。所以核心组件的改革对整个 Flume 的使用影响深远：

大大降低了对用户的要求，如核心组件的变化使得 Flume 的稳定使用不再依赖 zookeeper，用户无需去搭建 zookeeper 集群；另外用户也不再纠结于 OG 中的模糊概念（尤其是 physical nodes、logical nodes，agent、collector）。
有利于 Flume 和其他技术、hadoop 周边组件的整合，比如在 NG 版本中，Flume 轻松实现了和 jdbc、hbase 的集成。
将 OG 版本中复杂、大规模、不稳定的标签移除，Flume 实现了向灵活、轻便的转变，而且在功能上更加强大、可扩展性更高，这一点主要表现在用户使用 Flume 搭建日志收集集群的过程中，后面的章节会详细介绍。
删减节点角色，脱离 zookeeper
Zookeeper 是针对大型分布式系统的可靠协调系统，适用于有多类角色集群管理。比如在 hbase 中，对 HMaster、HRegionServer 的管理。
在 OG 版本中，Flume 的使用稳定性依赖 zookeeper。它需要 zookeeper 对其多类节点（agent、collector、master）的工作进行管理，尤其是在集群中配置多个 master 的情况下。当然，OG 也可以用内存的方式管理各类节点的配置信息，但是需要用户能够忍受在机器出现故障时配置信息出现丢失。所以说 OG 的稳定行使用是依赖 zookeeper 的。
而在 NG 版本中，节点角色的数量由 3 缩减到 1，不存在多类角色的问题，所以就不再需要 zookeeper 对各类节点协调的作用了，由此脱离了对 zookeeper 的依赖。由于 OG 的稳定使用对 zookeeper 的依赖表现在整个配置和使用过程中，这就要求用户掌握对 zookeeper 集群的搭建极其使用（尤其是要熟悉 zookeeper 数据文件夹 data，Flume 节点配置信息存放在此文件夹中）；掌握 Flume 中和 zookeeper 相关的配置。对初次接触 Flume 的用户来讲，这是非常痛苦的事。
用户配置变化之安装
OG 在安装时：

在 flume-env.sh 中设置$JAVA_HOME。
需要配置文件 flume-conf.xml。其中最主要的、必须的配置与 master 有关。集群中的每个 Flume 都需要配置 master 相关属性（如 flume.master.servers、flume.master.store、flume.master.serverid）。
如果想稳定使用 Flume 集群，还需要安装 zookeeper 集群，这需要用户对 zookeeper 有较深入的了解。
安装 zookeeper 之后，需要配置 flume-conf.xml 中的相关属性，如 flume.master.zk.use.external、flume.master.zk.servers。
在使用 OG 版本传输数据之前，需要启动 master、agent。
NG 在安装时，只需要在 flume-env.sh 中设置$JAVA_HOME。

用户配置变化之数据传输配置
OG 版本的配置途径有两个：

shell 命令：需要用户掌握 Flume shell 命令；
master console 页面：这是 OG 用户最常用的配置方式；弊端在于，除非用户熟悉复杂的各类 source，sink 配置函数以及格式（source：大约 25 个，sink：大约 46 个），否则在复杂的集群环境下，用户每次只能配置一个节点（指定 source、sink）来保证配置的准确性；
NG 的配置只需要一个配置文件，这个配置文件中存放 source、sink、channel 的配置。然后在启动 agent 时，使用一下命令指定这个配置文件。

结束语
从核心组件和用户的角度，Flume NG 给 Flume 带来的第一次革命。从核心组件来讲，NG 简化核心组件，移除了 OG 版本代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点；
另外 NG 脱离了 Flume 稳定性对 zookeeper 的依赖。从用户角度来讲，NG 版本对用户要求大大降低：
安装过程除了 java 无需配置复杂的 Flume 相关属性，也无需搭建 zookeeper 集群，安装过程几乎零工作量；
数据流的配置过程更加简单、合理，只需要实现 source、sink、channel 的简单配置即可。
————————————————
版权声明：本文为CSDN博主「if 0 = -I can」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_42018518/article/details/105558363