Flume是一种分布式、高可靠和高可用的服务,用于高效地收集、聚合和移动大量日志数据。它有一个简单而灵活的基于流数据流的体系结构。它具有可调的可靠性机制、故障转移和恢复机制,具有强大的容错能力。它使用一个简单的可扩展数据模型,允许在线分析应用程序。

Filebeat由两个主要组成部分组成:prospector和 harvesters。这些组件一起工作来读取文件并将事件数据发送到指定的output。

  Harvesters:负责读取单个文件的内容。harvesters逐行读取每个文件,并将内容发送到output中。每个文件都将启动一个harvesters。harvesters负责文件的打开和关闭,这意味着harvesters运行时,文件会保持打开状态。如果在收集过程中,即使删除了这个文件或者是对文件进行重命名,Filebeat依然会继续对这个文件进行读取,这时候将会一直占用着文件所对应的磁盘空间,直到Harvester关闭。默认情况下,Filebeat会一直保持文件的开启状态,直到超过配置的close_inactive参数,Filebeat才会把Harvester关闭。

  Prospector:负责管理Harvsters,并且找到所有需要进行读取的数据源。如果input type配置的是log类型,Prospector将会去配置路径下查找所有能匹配上的文件,然后为每一个文件创建一个Harvster。每个Prospector都运行在自己的Go routine里。

Filebeat目前支持两种Prospector类型:log和stdin。每个Prospector类型可以在配置文件定义多个。log Prospector将会检查每一个文件是否需要启动Harvster,启动的Harvster是否还在运行,或者是该文件是否被忽略(可以通过配置 ignore_order,进行文件忽略)。如果是在Filebeat运行过程中新创建的文件,只要在Harvster关闭后,文件大小发生了变化,新文件才会被Prospector选择到。

Flume 与 Filebeat 的比较

  • 重启时。filebeat不会造成数据丢失;flume虽然有断点续传功能,但是在channel中的数据会丢失;
  • 数据重复。filebeat和flume都会有。flume有些没有写入到pos文件中的数据也会重复发送。
  • 目录中文件回滚时。filebeat会自动处理,flume不能自动处理,处理起来比较麻烦。
  • 资源的占用。flume运行在jvm上,会占用较多的资源;filebeat对操作系统而言,是一个二进制文件,占用资源较少。
  • 系统的配置。flume可以与zookeeper结合,由zookeeper统一维护配置信息;fliebeat不能。
  • 数据完整性。flume对于每个event进行事务性处理,只有当收到sink的ack时,才会删除channel中的event;filebeat也可以做到。
  • 版本更新力度。flume最新1.8,filebeat6.5
  • flume可以配置flume Collector集群统一收集每个flume agent的日志,flume Collector具有failover模式。filebeat支持写入到logstash中。