分布式日志收集框架 Flume

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 1 需求分析 WebServer/ApplicationServer分散在各个机器上,然而我们依旧想在Hadoop平台上进行统计分析,如何将日志收集到Hadoop平台呢? 简单的这样吗? shell cp hadoop集群的机器上; hadoop fs -put ... / 显然该法面临着容错、负载均衡、高延迟、数据压缩等一系列问题这显然已经无法满足需求了! 不如问问神奇的Flume呢??? 只需要配置文件,轻松解决以上问题! 2 Flume概述 2.1 官网 Flume是一种分布式,可靠且可用的服务,用于有效地收集,聚合和移动大量日志数据。

0 Github

1 需求分析


WebServer/ApplicationServer分散在各个机器上,然而我们依旧想在Hadoop平台上进行统计分析,如何将日志收集到Hadoop平台呢?

  • 简单的这样吗?
shell cp hadoop集群的机器上;
hadoop fs -put ... /

显然该法面临着容错、负载均衡、高延迟、数据压缩等一系列问题
这显然已经无法满足需求了!

不如问问神奇的Flume呢???

只需要配置文件,轻松解决以上问题!

2 Flume概述

2.1 官网

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

2.2 设计目标

  • 可靠性
    当节点出现故障时,日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障,从强到弱依次分别为:end-to-end(收到数据agent首先将event写到磁盘上,当数据传送成功后,再删除;如果数据发送失败,可以重新发送。),Store on failure(这也是scribe采用的策略,当数据接收方crash时,将数据写到本地,待恢复后,继续发送),Best effort(数据发送到接收方后,不会进行确认)。
  • 扩展性
    Flume采用了三层架构,分别为agent,collector和storage,每一层均可以水平扩展。

其中,所有agent和collector由master统一管理,这使得系统容易监控和维护,且master允许有多个(使用ZooKeeper进行管理和负载均衡),这就避免了单点故障问题。

  • 管理性
    所有agent和colletor由master统一管理,这使得系统便于维护。多master情况,Flume利用ZooKeeper和gossip,保证动态配置数据的一致性。用户可以在master上查看各个数据源或者数据流执行情况,且可以对各个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。
  • 功能可扩展性
    用户可以根据需要添加自己的agent,collector或者storage。此外,Flume自带了很多组件,包括各种agent(file, syslog等),collector和storage(file,HDFS等)。

2.3 主流竞品对比


其他的还有比如:

  • Logstash: ELK(ElasticsSearch, Logstash, Kibana)
  • Chukwa: Yahoo/Apache, 使用Java语言开发, 负载均衡不是很好, 已经不维护了。
  • Fluentd: 和Flume类似, Ruby开发。

2.4 发展史

  • Cloudera公司提出0.9.2,叫Flume-OG
  • 2011年Flume-728编号,重要里程碑(Flume-NG),贡献给Apache社区
  • 2012年7月 1.0版本
  • 2015年5月 1.6版本
  • ~ 1.9版本

3 核心架构及其组件

3.1 core架构

在这里插入图片描述

3.2 核心的组件

顺便来看看官方文档

3.2.1 Source - 收集

指定数据源(Avro, Thrift, Spooling, Kafka, Exec)

3.2.2 Channel - 聚集

把数据暂存(Memory, File, Kafka等用的比较多)

3.2.3 Sink - 输出

把数据写至某处(HDFS, Hive, Logger, Avro, Thrift, File, ES, HBase, Kafka等)

multi-agent flow


为了跨多个代理或跳数据流,先前代理的接收器和当前跳的源需要是avro类型,接收器指向源的主机名(或IP地址)和端口。

Consolidation合并

日志收集中非常常见的情况是大量日志生成客户端将数据发送到连接到存储子系统的少数消费者代理。 例如,从数百个Web服务器收集的日志发送给写入HDFS集群的十几个代理。
这可以通过使用avro接收器配置多个第一层代理在Flume中实现,所有这些代理都指向单个代理的avro源(同样,您可以在这种情况下使用thrift源/接收器/客户端)。 第二层代理上的此源将接收的事件合并到单个信道中,该信道由信宿器消耗到其最终目的地。

Multiplexing the flow

Flume支持将事件流多路复用到一个或多个目的地。 这是通过定义可以复制或选择性地将事件路由到一个或多个信道的流复用器来实现的。

上面的例子显示了来自代理“foo”的源代码将流程扩展到三个不同的通道。 扇出可以复制或多路复用。 在复制流的情况下,每个事件被发送到所有三个通道。 对于多路复用情况,当事件的属性与预配置的值匹配时,事件将被传递到可用通道的子集。 例如,如果一个名为“txnType”的事件属性设置为“customer”,那么它应该转到channel1和channel3,如果它是“vendor”,那么它应该转到channel2,否则转到channel3。 可以在代理的配置文件中设置映射。

4 环境配置与部署

4.1 系统需求

  • 系统
    macOS 10.14.14
  • Java运行时环境
    Java 1.8或更高版本
  • 内存源
    通道或接收器使用的配置的足够内存
  • 磁盘空间
    通道或接收器使用的配置的足够磁盘空间
  • 目录权限
    代理使用的目录的读/写权限

4.2 下载与安装

4.3 配置

  • 查看安装路径
  • 系统配置文件
export FLUME_VERSION=1.9.0
export FLUME_HOME=/usr/local/Cellar/flume/1.9.0/libexec
export FLUME_CONF_DIR=$FLUME_HOME/conf
export PATH=$FLUME_HOME/bin:$PATH
  • flume配置文件
    配置JAVA_HOME

  • 验证
    bin下的命令执行文件

安装成功

5 实战

使用Flume的核心就在于配置文件

  • 配置Source
  • 配置Channel
  • 配置Sink
  • 组织在一起

5.1 场景1

看看官网的第一个案例

# example.conf: A single-node Flume configuration

# Name the components on this agent
a1.sources = r1
a1.sinks = k1
a1.channels = c1

# Describe/configure the source
a1.sources.r1.type = netcat
a1.sources.r1.bind = localhost
a1.sources.r1.port = 44444

# Describe the sink
a1.sinks.k1.type = logger

# Use a channel which buffers events in memory
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1

a1:agent名称
r1:Source名称
k1:Sink名称
c1:Channel名称

参考

https://tech.meituan.com/2013/12/09/meituan-flume-log-system-architecture-and-design.html

更多请关注JavaEdge 公-众-号

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
3月前
|
存储 数据采集 数据处理
【Flume拓扑揭秘】掌握Flume的四大常用结构,构建强大的日志收集系统!
【8月更文挑战第24天】Apache Flume是一个强大的工具,专为大规模日志数据的收集、聚合及传输设计。其核心架构包括源(Source)、通道(Channel)与接收器(Sink)。Flume支持多样化的拓扑结构以适应不同需求,包括单层、扇入(Fan-in)、扇出(Fan-out)及复杂多层拓扑。单层拓扑简单直观,适用于单一数据流场景;扇入结构集中处理多源头数据;扇出结构则实现数据多目的地分发;复杂多层拓扑提供高度灵活性,适合多层次数据处理。通过灵活配置,Flume能够高效构建各种规模的数据收集系统。
69 0
|
1月前
|
SQL 分布式计算 Hadoop
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
42 2
|
1月前
|
存储 数据采集 分布式计算
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
41 1
|
2月前
|
运维 NoSQL Java
SpringBoot接入轻量级分布式日志框架GrayLog技术分享
在当今的软件开发环境中,日志管理扮演着至关重要的角色,尤其是在微服务架构下,分布式日志的统一收集、分析和展示成为了开发者和运维人员必须面对的问题。GrayLog作为一个轻量级的分布式日志框架,以其简洁、高效和易部署的特性,逐渐受到广大开发者的青睐。本文将详细介绍如何在SpringBoot项目中接入GrayLog,以实现日志的集中管理和分析。
216 1
|
3月前
|
存储 分布式计算 大数据
【Flume的大数据之旅】探索Flume如何成为大数据分析的得力助手,从日志收集到实时处理一网打尽!
【8月更文挑战第24天】Apache Flume是一款高效可靠的数据收集系统,专为Hadoop环境设计。它能在数据产生端与分析/存储端间搭建桥梁,适用于日志收集、数据集成、实时处理及数据备份等多种场景。通过监控不同来源的日志文件并将数据标准化后传输至Hadoop等平台,Flume支持了性能监控、数据分析等多种需求。此外,它还能与Apache Storm或Flink等实时处理框架集成,实现数据的即时分析。下面展示了一个简单的Flume配置示例,说明如何将日志数据导入HDFS进行存储。总之,Flume凭借其灵活性和强大的集成能力,在大数据处理流程中占据了重要地位。
70 3
|
3月前
|
消息中间件 JSON 自然语言处理
Python多进程日志以及分布式日志的实现方式
python日志模块logging支持多线程,但是在多进程下写入日志文件容易出现下面的问题: PermissionError: [WinError 32] 另一个程序正在使用此文件,进程无法访问。 也就是日志文件被占用的情况,原因是多个进程的文件handler对日志文件进行操作产生的。
|
3月前
|
存储 监控 数据可视化
性能监控之JMeter分布式压测轻量日志解决方案
【8月更文挑战第11天】性能监控之JMeter分布式压测轻量日志解决方案
92 0
性能监控之JMeter分布式压测轻量日志解决方案
|
25天前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
105 2
基于Redis的高可用分布式锁——RedLock
|
1天前
|
NoSQL Redis
Redis分布式锁如何实现 ?
Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
30 16
下一篇
无影云桌面