热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

Flume和Logstash对比

Flume和Logstash对比更多干货分布式实战(干货)springcloud实战(干货)mybatis实战ÿ

Flume和Logstash 对比


更多干货


  • 分布式实战(干货)
  • spring cloud 实战(干货)
  • mybatis 实战(干货)
  • spring boot 实战(干货)
  • React 入门实战(干货)
  • 构建中小型互联网企业架构(干货)
  • python 学习持续更新
  • ElasticSearch 笔记
  • kafka storm 实战 (干货)

一、概述

在某个Logstash的场景下,我产生了为什么不能用Flume代替Logstash的疑问,因此查阅了不少材料在这里总结,大部分都是前人的工作经验下,加了一些我自己的思考在里面,希望对大家有帮助。

大数据的数据采集工作是大数据技术中非常重要、基础的部分,数据不会平白无故地跑到你的数据平台软件中,你得用什么东西把它从现有的设备(比如服务器,路由器、交换机、防火墙、数据库等)采集过来,再传输到你的平台中,然后才会有后面更加复杂高难度的处理技术。

目前,Flume和Logstash是比较主流的数据采集工具(主要用于日志采集),但是很多人还不太明白两者的区别,特别是对用户来说,具体场景使用合适的采集工具,可以大大提高效率和可靠性,并降低资源成本。

我们先来看Logstash,然后看Flume


二、一个通用的数据采集模型

image

普适环境的数据采集 其中,数据采集和存储是必要的环节,其他并不一定需要。是不是很简单?本来编程其实就是模块化的东西,没有那么难。但是这毕竟只是一个粗略的通用模型,不同开源社区或者商业厂家开发的时候都会有自己的考虑和目的。我们在本文要讨论的Flume和Logstash原则上都属于数据采集这个范畴,尽管两者在技术上或多或少都自带了一些缓冲、过滤等等功能。


三、Logstash

Logstash是ELK组件中的一个。所谓ELK就是指,ElasticSearch、Logstash、Kibana这三个组件。那么为什么这三个组件要合在一起说呢?第一,这三个组件往往是配合使用的(ES负责数据的存储和索引,Logstash负责数据采集和过滤转换,Kibana则负责图形界面处理);第二,这三个组件又先后被收购于Elastic.co公司名下。是不是很巧合?这里说个题外话,原ELK Stack在5.0版本加入Beats(一种代理)套件后改称为Elastic Stack,这两个词是一个意思,只不过因为增加了Beats代理工具,改了个名字。

Logstash诞生于2009年8有2日,其作者是世界著名的虚拟主机托管商DreamHost的运维工程师乔丹 西塞(Jordan Sissel)。Logstash的开发很早,对比一下,Scribed诞生于2008年,Flume诞生于2010年,Graylog2诞生于2010年,Fluentd诞生于2011年。2013年,Logstash被ElasticSearch公司收购。这里顺便提一句,Logstash是乔丹的作品,所以带着独特的个人性格,这一点不像Facebook的Scribe,Apache的Flume开源基金项目。

Logstash的设计非常规范,有三个组件,其分工如下:


  • 1、Shipper 负责日志收集。职责是监控本地日志文件的变化,并输出到 Redis 缓存起来;
  • 2、Broker 可以看作是日志集线器,可以连接多个 Shipper 和多个 Indexer;
  • 3、Indexer 负责日志存储。在这个架构中会从 Redis 接收日志,写入到本地文件。

这里要说明,因为架构比较灵活,如果不想用 Logstash 的存储,也可以对接到 Elasticsearch,这也就是前面所说的 ELK 的套路了。

image

如果继续细分,Logstash也可以这么解剖来看

image

Logstash三个工作阶段 貌似到这里。。。好像就讲完了。。。读者朋友们不要骂我,因为Logstash就是这么简约,全部将代码集成,程序员不需要关心里面是如何运转的。

Logstash最值得一提的是,在Filter plugin部分具有比较完备的功能,比如grok,能通过正则解析和结构化任何文本,Grok 目前是Logstash最好的方式对非结构化日志数据解析成结构化和可查询化。此外,Logstash还可以重命名、删除、替换和修改事件字段,当然也包括完全丢弃事件,如debug事件。还有很多的复杂功能供程序员自己选择,你会发现这些功能Flume是绝对没有(以它的轻量级线程也是不可能做到的)。当然,在input和output两个插件部分也具有非常多类似的可选择性功能,程序员可以自由选择,这一点跟Flume是比较相似的。


四、Flume

Logstash因为集成化设计,所以理解起来其实不难。现在我们讲讲Flume,这块内容就有点多了。


1、Flume OG

最早Flume是由Cloudrea开发的日志收集系统,初始的发行版本叫做Flume OG(就是original generation的意思),作为开源工具,一经公布,其实是很受关注的一套工具,但是后面随着功能的拓展,暴露出代码工程臃肿、核心组件设计不合理、核心配置不标准等各种缺点。尤其是在Flume OG的最后一个发行版本0.94.0中,日志传输不稳定的现象特别严重。我们来看看Flume OG到底有什么问题。

image

Flume OG架构图 直到现在,你在网络上搜索Flume相关资料的时候还会经常出现Flume OG的结构图,这对新人来说是很不友好的,很容易引起误导,请读者朋友们一定要注意!我们可以看到Flume OG有三种角色的节点:代理节点(agent)、收集节点(collector)、主节点(master)。

流程理解起来也并不困难:agent 从各个数据源收集日志数据,将收集到的数据集中到 collector,然后由收集节点汇总存入 hdfs。master 负责管理 agent,collector 的活动。agent、collector 都称为 node,node 的角色根据配置的不同分为 logical node(逻辑节点)、physical node(物理节点)。对logical nodes和physical nodes的区分、配置、使用一直以来都是使用者最头疼的地方。

Flume OG中节点的构成 agent、collector 由 source、sink 组成,代表在当前节点数据是从 source 传送到 sink。

就算是外行人,看到这里也觉得很头大,这尼玛是谁设计出来的破玩意?

各种问题的暴露,迫使开发者痛下决心,抛弃原有的设计理念,彻底重写Flume。于是在2011 年 10 月 22 号,Cloudera 完成了 Flume-728,对 Flume 进行了里程碑式的改动:重构核心组件、核心配置以及代码架构,重构后的版本统称为 Flume NG(next generation下一代的意思);改动的另一原因是将 Flume 纳入 apache 旗下,Cloudera Flume 改名为 Apache Flume,所以现在Flume已经是Apache ETL工具集中的一员。

这里说个题外话,大家都知道,通常情况下大公司,特别是大型IT公司是比较排斥使用一些不稳定的新技术的,也不喜欢频繁变换技术,这很简单,因为变化很容易导致意外。举个例子,Linux发展了二十多年了,大部分公司都在使用RedHat、CentOS和Ubuntu这类旨在提供稳定、兼容好的版本,如果你看到一家公司用的是Linux新内核,那多半是一家新公司,需要用一些新技术在竞争中处于上风。


1、Flume NG

好,了解了一些历史背景,现在我们可以放上Flume NG的结构图了

image

Flume NG结构图 卧槽,是不是很简单?!对比一下OG的结构,外行人都会惊叹:so easy!

这次开发者吸取了OG的血淋林教训,将最核心的几块部分做了改动:


  • 1、NG 只有一种角色的节点:代理节点(agent),而不是像OG那么多角色;
  • 2、没有collector,master节点。这是核心组件最核心的变化;
  • 3、去除了physical nodes、logical nodes的概念和相关内容;
  • 4、agent 节点的组成也发生了变化,NG agent由source、sink、channel组成。

那么这么做有什么好处呢?简单概括有这么三点:


  • 1、NG 简化核心组件,移除了 OG 版本代码工程臃肿、核心组件设计不合理、核心配置不标准等缺点,使得数据流的配置变得更简单合理,这是比较直观的一个改进点;

  • 2、NG 脱离了 Flume 稳定性对 zookeeper 的依赖。在早期的OG版本中,Flume 的使用稳定性依赖 zookeeper。它需要 zookeeper 对其多类节点(agent、collector、master)的工作进行管理,尤其是在集群中配置多个 master 的情况下。当然,OG 也可以用内存的方式管理各类节点的配置信息,但是需要用户能够忍受在机器出现故障时配置信息出现丢失。所以说 OG 的稳定行使用是依赖 zookeeper 的。

  • 3、NG 版本对用户要求大大降低:安装过程除了java无需配置复杂的Flume相关属性,也无需搭建zookeeper集群,安装过程几乎零工作量。

有人很不解,怎么突然冒出来一个Zookeeper这个概念,这是个啥玩意?简单的说,Zookeeper 是针对大型分布式系统的可靠协调系统,适用于有多类角色集群管理。你可以把它理解为整个Hadoop的总管家,负责整个系统所有组件之间的协调工作管理。这个组件平时很不起眼,但非常重要。好比一支篮球队,五个队员个个都是巨星,所以我们平时都习惯关注这五个人,但是整个球队的获胜缺不了教练的协调组织、战术安排,Zookeeper就好比是整个Hadoop系统的教练。比喻虽然有些生硬,只是想说明Zookeeper的重要性,也侧面说明NG在摆脱了Zookeeper的依赖后变得更加轻便,灵活。

说个题外话,OG版本的使用文档有90多页,而NG只用 20 多页的内容就完成了新版 Flume 的使用说明。可见在科学研究领域,人类总是在追求真理,而真理总是可以用最简单的语言描述出来。

到这里差不多Flume就讲的差不多了,因为这个线程工具从原理上讲真的很简单,三段式的结构:源(Source输入)——存储(Channel管道)——出口(Sink目标输出)。但也因为涉及到这三个结构,所以做配置就比较复杂,这里举个例子,我们看看Flume在一些场景下是如何搭建布置的。

image


Flume集群部署


这里要纠正几个很多初学Flume朋友们的误区。首先,Flume已经可以支持一个Agent中有多个不同类型的channel和sink,我们可以选择把Source的数据复制,分发给不同的目的端口,比如:

image


Flume的多重复用


其次,Flume还自带了分区和拦截器功能,因此不是像很多实验者认为的没有过滤功能(当然我承认Flume的过滤功能比较弱)。

读者可能会隐约感觉到,Flume在集群中最擅长的事情就是做路由了,因为每一个Flume Agent相连就构成了一条链路,这也是众多采集工具中Flume非常出色的亮点。但是也正因为如此,如果有一个Flume Agent出了问题,那么整个链路也会出现问题,所以在集群中需要设计分层架构等来实现冗余备份。但这么一来,配置又会变得很麻烦。


五、对比

把Logstash和Flume都讲完了,我们最后可以对比总结一下了。

首先从结构对比,我们会惊人的发现,两者是多么的相似!Logstash的Shipper、Broker、Indexer分别和Flume的Source、Channel、Sink各自对应!只不过是Logstash集成了,Broker可以不需要,而Flume需要单独配置,且缺一不可,但这再一次说明了计算机的设计思想都是通用的!只是实现方式会不同而已。

从程序员的角度来说,上文也提到过了,Flume是真的很繁琐,你需要分别作source、channel、sink的手工配置,而且涉及到复杂的数据采集环境,你可能还要做多个配置,这在上面提过了,反过来说Logstash的配置就非常简洁清晰,三个部分的属性都定义好了,程序员自己去选择就行,就算没有,也可以自行开发插件,非常方便。当然了,Flume的插件也很多,但Channel就只有内存和文件这两种(其实现在不止了,但常用的也就两种)。读者可以看得出来,两者其实配置都是非常灵活的,只不过看场景取舍罢了。

其实从作者和历史背景来看,两者最初的设计目的就不太一样。Flume本身最初设计的目的是为了把数据传入HDFS中(并不是为了采集日志而设计,这和Logstash有根本的区别),所以理所应当侧重于数据的传输,程序员要非常清楚整个数据的路由,并且比Logstash还多了一个可靠性策略,上文中的channel就是用于持久化目的,数据除非确认传输到下一位置了,否则不会删除,这一步是通过事务来控制的,这样的设计使得可靠性非常好。相反,Logstash则明显侧重对数据的预处理,因为日志的字段需要大量的预处理,为解析做铺垫。

回过来看我当初为什么先讲Logstash然后讲Flume?这里面有几个考虑,其一:Logstash其实更有点像通用的模型,所以对新人来说理解起来更简单,而Flume这样轻量级的线程,可能有一定的计算机编程基础理解起来更好;其二:目前大部分的情况下,Logstash用的更加多,这个数据我自己没有统计过,但是根据经验判断,Logstash可以和ELK其他组件配合使用,开发、应用都会简单很多,技术成熟,使用场景广泛。相反Flume组件就需要和其他很多工具配合使用,场景的针对性会比较强,更不用提Flume的配置过于繁琐复杂了。

最后总结下来,我们可以这么理解他们的区别:Logstash就像是买来的台式机,主板、电源、硬盘,机箱(Logstash)把里面的东西全部装好了,你可以直接用,当然也可以自己组装修改;Flume就像提供给你一套完整的主板,电源、硬盘,Flume没有打包,只是像说明书一样指导你如何组装,才能运行的起来。


推荐阅读
  • 【重识云原生】第四章云网络4.8.3.2节——Open vSwitch工作原理详解
    2OpenvSwitch架构2.1OVS整体架构ovs-vswitchd:守护程序,实现交换功能,和Linux内核兼容模块一起,实现基于流的交换flow-basedswitchin ... [详细]
  • [译]技术公司十年经验的职场生涯回顾
    本文是一位在技术公司工作十年的职场人士对自己职业生涯的总结回顾。她的职业规划与众不同,令人深思又有趣。其中涉及到的内容有机器学习、创新创业以及引用了女性主义者在TED演讲中的部分讲义。文章表达了对职业生涯的愿望和希望,认为人类有能力不断改善自己。 ... [详细]
  • 本文介绍了高校天文共享平台的开发过程中的思考和规划。该平台旨在为高校学生提供天象预报、科普知识、观测活动、图片分享等功能。文章分析了项目的技术栈选择、网站前端布局、业务流程、数据库结构等方面,并总结了项目存在的问题,如前后端未分离、代码混乱等。作者表示希望通过记录和规划,能够理清思路,进一步完善该平台。 ... [详细]
  • 开发笔记:计网局域网:NAT 是如何工作的?
    篇首语:本文由编程笔记#小编为大家整理,主要介绍了计网-局域网:NAT是如何工作的?相关的知识,希望对你有一定的参考价值。 ... [详细]
  • Linux如何安装Mongodb的详细步骤和注意事项
    本文介绍了Linux如何安装Mongodb的详细步骤和注意事项,同时介绍了Mongodb的特点和优势。Mongodb是一个开源的数据库,适用于各种规模的企业和各类应用程序。它具有灵活的数据模式和高性能的数据读写操作,能够提高企业的敏捷性和可扩展性。文章还提供了Mongodb的下载安装包地址。 ... [详细]
  • Oracle优化新常态的五大禁止及其性能隐患
    本文介绍了Oracle优化新常态中的五大禁止措施,包括禁止外键、禁止视图、禁止触发器、禁止存储过程和禁止JOB,并分析了这些禁止措施可能带来的性能隐患。文章还讨论了这些禁止措施在C/S架构和B/S架构中的不同应用情况,并提出了解决方案。 ... [详细]
  • 一句话解决高并发的核心原则
    本文介绍了解决高并发的核心原则,即将用户访问请求尽量往前推,避免访问CDN、静态服务器、动态服务器、数据库和存储,从而实现高性能、高并发、高可扩展的网站架构。同时提到了Google的成功案例,以及适用于千万级别PV站和亿级PV网站的架构层次。 ... [详细]
  • 基于PgpoolII的PostgreSQL集群安装与配置教程
    本文介绍了基于PgpoolII的PostgreSQL集群的安装与配置教程。Pgpool-II是一个位于PostgreSQL服务器和PostgreSQL数据库客户端之间的中间件,提供了连接池、复制、负载均衡、缓存、看门狗、限制链接等功能,可以用于搭建高可用的PostgreSQL集群。文章详细介绍了通过yum安装Pgpool-II的步骤,并提供了相关的官方参考地址。 ... [详细]
  • 本文详细介绍了SQL日志收缩的方法,包括截断日志和删除不需要的旧日志记录。通过备份日志和使用DBCC SHRINKFILE命令可以实现日志的收缩。同时,还介绍了截断日志的原理和注意事项,包括不能截断事务日志的活动部分和MinLSN的确定方法。通过本文的方法,可以有效减小逻辑日志的大小,提高数据库的性能。 ... [详细]
  • 图解redis的持久化存储机制RDB和AOF的原理和优缺点
    本文通过图解的方式介绍了redis的持久化存储机制RDB和AOF的原理和优缺点。RDB是将redis内存中的数据保存为快照文件,恢复速度较快但不支持拉链式快照。AOF是将操作日志保存到磁盘,实时存储数据但恢复速度较慢。文章详细分析了两种机制的优缺点,帮助读者更好地理解redis的持久化存储策略。 ... [详细]
  • 基于事件驱动的并发编程及其消息通信机制的同步与异步、阻塞与非阻塞、IO模型的分类
    本文介绍了基于事件驱动的并发编程中的消息通信机制,包括同步和异步的概念及其区别,阻塞和非阻塞的状态,以及IO模型的分类。同步阻塞IO、同步非阻塞IO、异步阻塞IO和异步非阻塞IO等不同的IO模型被详细解释。这些概念和模型对于理解并发编程中的消息通信和IO操作具有重要意义。 ... [详细]
  • CentOS 7部署KVM虚拟化环境之一架构介绍
    本文介绍了CentOS 7部署KVM虚拟化环境的架构,详细解释了虚拟化技术的概念和原理,包括全虚拟化和半虚拟化。同时介绍了虚拟机的概念和虚拟化软件的作用。 ... [详细]
  • GAMETECH腾讯云游戏行业技术沙龙成都站圆满落幕
    11月13日,由腾讯云主办、游戏茶馆协办的2020年首场GAME-TECH腾讯云游戏行业技术沙龙在成都圆满落幕。本次沙龙邀请了腾讯云游戏行业解决方案总监宋永周、腾讯云游戏行业高级解决方案架构师曾梓恩、腾讯云游戏行业高级产品架构师郑晓曦、腾讯云游戏行业高级解决方案架构师温球良和天美L1(王者荣耀)服务器技术副总监杨光,为参会同行们带来了干货满满的技术建议。本文介绍了腾讯云游戏云的优势和为不同游戏研运场景提供的服务。腾讯云在中国游戏云服务市场领跑,成为众多游戏开发者的合作伙伴。 ... [详细]
  • 集成电路企业在进行跨隔离网数据交换时面临着安全性问题,传统的数据交换方式存在安全性堪忧、效率低下等问题。本文以《Ftrans跨网文件安全交换系统》为例,介绍了如何通过丰富的审批流程来满足企业的合规要求,保障数据交换的安全性。 ... [详细]
  • 本文介绍了如何使用双路由器有线搭建一个小型的局域网网络,解决家庭或公司多个网络设备无法同时上网的问题。详细讲解了两种简单快速的组网方式,并提供了具体的设置步骤和注意事项。 ... [详细]
author-avatar
jelly62_736
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有