Flume使用总结

发表于

Flume使用总结

Flume可能是现阶段最为优秀的开源分布式采集日志框架，高可靠性，高可用性，并且可以定制多种数据发送方，同时还可以进行简单的日志处理，满足基本的数据需求。 作为Apache基金会的顶级项目，Flume发展迅速，现在已经发布了1.4.0版本。对于开发者来说，0.x与1.x版本之间还是有相当的差别的。

  • 0.x版本属于早期版本，它将整个框架分成了有机的4部分
    • master
      • 协调管理agent & colletor的配置信息，是Flume集群的控制节点
    • agent
      • 将数据源(DB or Log or others)的数据发送给collector
    • collector
      • 将多个agent发来的数据汇总后，加载到storage中
    • storage
      • Flume汇总日志的存储系统，可以是文本文件，也可以是分布式文件系统或架构，如HDFS，Hive，HBase，MongoDB等等
  • 1.x版本则对上面的结构做了大刀阔斧的改进：只剩下agent和storage作为Flume的模块(实际上，storage严格说都不能算作是Flume的模块)，这样精简的效果是使得彼此的之间的通讯更为透明
  • 0.x版本中使用多个master来实现容错和安全机制(zookeeper管理)，而在1.x版本中，每一个agent都可以被配置成master，只需要接收相应的数据即可，动态增加节点更为方便
    通过以上总结，我们基本了解了Flume的2代产品，现在着重介绍1.x版本(以下未特别说明的，Flume都是指代1.4.0)。 Flume agent主要有3个组件：
  • Source
    • 完成对日志的采集，将收集到的数据分成transtion & event 输出到channel中
  • Channel
    • 提供一个类似管道的功能，对Source提供的数据进行有序缓存

  • Sink

    • 接收由Channel传送的数据，写入到相应的文件系统进行存储，或者再次提交到别的agent或者远程服务器
      flume_ct 对于Source文件的读取，Flume提供了2种方式：

  • ExecSource

    • 通过Linux/Unix终端命令的方式持续输出最新的数据(如tail -F filename)，在这种方式下，文件名不能使用通配符，需要确定名称
  • SpoolSource
    • 检测配置文件中读取目录下新增的文件，并读出文件中的数据
      这里需要声明的是：
  • spool目录下的文件不可以2次编辑
  • spool目录下应只含有文件，不得嵌套目录
    鉴于此，可以在实际操作中，配合log4j使用，将日志文件进行定时切割，通过Flume集中传输。 对比这2种读取方式：
  • ExecSource可以实现对日志的实时收集，但是，当Flume由于故障停止运行或者指令发生错误异常时，将无法正常收集到数据，无法保证数据的完整性
  • SpoolSource没有办法完全实时的收集数据，但可以用分割文件的方式保证数据的完整性，当分割的时间段越小，也就越接近实时的效果，对于实时性要求不告的情况支持得更好
  • 如果由于服务器限制或者Web App对分割日志的不支持，可以选择2种方式结合使用
    在Flume中，Channel是一个很重要的组件，它有以下集中实现：
  • MemoryChannel
  • JDBC Channel
  • MemoryRecoverChannel
  • FileChannel
    MemoryChannel可以实现高速大量吞吐，但是比较消耗内存，同时也无法保证数据的完整性。MemoryChannel在官方文档中已经建议使用FileChannel来替换。 FileChannel可以很好的保证数据的完整性与一致性。在具体配置FileChannel时，建议将传输目录和程序日志文件保存的目录设置不同的磁盘，以便提高传输效率。 Sink在设置存储数据时，可以向各类文件系统中，数据库中，hadoop中，远程服务器存储数据。在日志数据较少时，可以将数据存储在文件系统中，并且设定一定的时间间隔将数据保存到合适的文件系统。在日志数据较多时，可以将相应的日志数据进行简单清洗，然后存储到Hadoop中，便于日后进行相应的数据分析，同时也减少后期ETL的负担。