日志收集组件flume和logstash对比

日志是解决生产环境中，线上问题的重要途经。日志的种类很多，基本上大多数软件都提供了日志输出，只是格式不同罢了。像操作系统日志，nginx日志，数据库日志，web应用日志等。常用的日志收集像ELK家族（Elasticsearch,Logstash,Kibana）。服务端文件收集可能会用到Filebeat，一款可靠的日志文件收集agent。Flume更多的应用场景是大数据技术栈的数据收集，flume采样java开发，早期项目flume-og，由于过于臃肿，已经重构过，并命名为flume-ng。

通用日志收集方案，数据流转通常如下：

日志平台数据流图

其中flume和logstash可以工作在数据采集、过滤、数据转换这三个位置。对这个三个功能的支持上，flume在数据过滤和数据转换（比如异构日志结构化）上插件较少些，很多时候可能需要自己开发。

下面介绍下flume和logstash的工作模式，和各自核心组件功能。

如图，惊人的相似。是的，设计思想基本一致。logstash和flume的这三个核心组件，都是通过插件的形式提供，方便自定义插件扩展。sink/source负责数据采集，filter负责数据过滤，output/sink负责数据输出。日志收集主键核心功能就是从A采集数据，加工处理（有时甚至不需要此步骤），然后输出到B存储，供用户查询检索日志信息。下面会主要讲述flume的工作原理。

flume数据流转图

其中intercepter组成链式调用。在数据到达channel之前会进行过滤处理。sourc采集来的数据会根据配置分发到channel中，channel维持一个内存队列（可以内存队列和持久化队列结合使用）。拿MemoryChannel举例，MemoryChannel包含三个LinkedBlockingDeque队列，putList,takeList和queue，并且提供了内存队列容量控制配置。由于往channel中放数据是顺序的（遍历配置中需要发送数据的channel列表），某个前面的内存队列容量满后，同样会阻塞后续channel获取数据。flume还提供了类似事务的机制，保证数据在source、channel和sink中流转的可靠交付。但是在flume节点故障（比如宕机）上，由于使用了内存队列，还是会存在数据丢失情况。建议对数据可靠性要求较高的场景使用FileChannel或其他提供持久化功能的队列。一般推荐内存队列和磁盘队列混用，折衷满足吞吐性能和避免内存被撑爆（内存队列满会发送到磁盘队列缓冲）。

了解了flume和logstash的工作机制，下面进行一些选型上的比较。

简单来讲，flume擅长数据路由，有条件分发数据，采用异步模式。虽说是异步模式，但是极端情况还是会出现阻塞问题，下文会专门讲解。logstash采样Ruby开发，6.x版本已经运行在jvm上，并且支持java插件开发。选型上，如果专注定制化开发和数据分发路由需求建议使用flume，如果仅仅是简单使用，推荐比较好上手的logstash。