【问题标题】:How can I force Flume-NG to process the backlog of events after a sink failed?在 sink 失败后,如何强制 Flume-NG 处理积压的事件?
【发布时间】:2013-01-14 20:16:29
【问题描述】:

我正在尝试设置 Flume-NG 从一堆服务器(主要运行 Tomcat 实例和 Apache Httpd)收集各种日志,并将它们转储到 5 节点 Hadoop 集群上的 HDFS 中。设置如下所示:

每个应用程序服务器将相关日志尾随到一个执行源(每种日志类型一个:java、httpd、syslog),然后通过 FileChannel 将它们输出到 Avro 接收器。在每台服务器上,不同的源、通道和接收器由一个代理管理。事件由驻留在 Hadoop 集群(也托管 SecondaryNameNode 和 Jobtracker 的节点)上的 AvroSource 接收。对于每个日志类型,都有一个 AvroSource 在不同的端口上侦听。事件通过 FileChannel 进入 HDFS Sink,HDFS Sink 使用 FlumeEventAvro EventSerializer 和 Snappy 压缩保存事件。

问题:Hadoop 节点上管理 HDFS 接收器(同样,每个日志类型一个)的代理在几个小时后失败,因为我们没有更改 JVM 的堆大小。从那时起,该节点上的 FileChannel 以及应用服务器上的 FileChannel 收集了大量事件,因为 Hadoop 节点上的 FileChannel 已达到其最大容量。当我解决了这个问题时,我无法让 Hadoop 节点上的代理足够快地处理积压,因此它可以恢复正常运行。 FileChannel 在接收事件之前保存事件的 tmp 目录的大小一直在增长。此外,HDFS 写入似乎真的很慢。 有没有办法强制 Flume 在摄取新事件之前先处理积压?下面的配置是最优的吗?可能相关:写入 HDFS 的文件非常小,大约 1 - 3 MB 左右。对于 64MB 的 HDFS 默认块大小以及未来的 MR 操作,这肯定不是最佳选择。我应该使用什么设置来收集足够大的文件中的事件以容纳 HDFS 块大小? 我感觉 Hadoop 节点上的配置不正确,我怀疑 BatchSize、RollCount 和相关参数的值是关闭的,但我不确定最佳值应该是什么。

应用服务器上的示例配置:

agent.sources=syslogtail httpdtail javatail
agent.channels=tmpfile-syslog tmpfile-httpd tmpfile-java
agent.sinks=avrosink-syslog avrosink-httpd avrosink-java

agent.sources.syslogtail.type=exec
agent.sources.syslogtail.command=tail -F /var/log/messages
agent.sources.syslogtail.interceptors=ts
agent.sources.syslogtail.interceptors.ts.type=timestamp
agent.sources.syslogtail.channels=tmpfile-syslog
agent.sources.syslogtail.batchSize=1

...

agent.channels.tmpfile-syslog.type=file
agent.channels.tmpfile-syslog.checkpointDir=/tmp/flume/syslog/checkpoint
agent.channels.tmpfile-syslog.dataDirs=/tmp/flume/syslog/data

...

agent.sinks.avrosink-syslog.type=avro
agent.sinks.avrosink-syslog.channel=tmpfile-syslog
agent.sinks.avrosink-syslog.hostname=somehost
agent.sinks.avrosink-syslog.port=XXXXX
agent.sinks.avrosink-syslog.batch-size=1

Hadoop 节点上的示例配置

agent.sources=avrosource-httpd avrosource-syslog avrosource-java
agent.channels=tmpfile-httpd tmpfile-syslog tmpfile-java
agent.sinks=hdfssink-httpd hdfssink-syslog hdfssink-java

agent.sources.avrosource-java.type=avro
agent.sources.avrosource-java.channels=tmpfile-java
agent.sources.avrosource-java.bind=0.0.0.0
agent.sources.avrosource-java.port=XXXXX

...

agent.channels.tmpfile-java.type=file
agent.channels.tmpfile-java.checkpointDir=/tmp/flume/java/checkpoint
agent.channels.tmpfile-java.dataDirs=/tmp/flume/java/data
agent.channels.tmpfile-java.write-timeout=10
agent.channels.tmpfile-java.keepalive=5
agent.channels.tmpfile-java.capacity=2000000

...

agent.sinks.hdfssink-java.type=hdfs
agent.sinks.hdfssink-java.channel=tmpfile-java
agent.sinks.hdfssink-java.hdfs.path=/logs/java/avro/%Y%m%d/%H
agent.sinks.hdfssink-java.hdfs.filePrefix=java-
agent.sinks.hdfssink-java.hdfs.fileType=DataStream
agent.sinks.hdfssink-java.hdfs.rollInterval=300
agent.sinks.hdfssink-java.hdfs.rollSize=0
agent.sinks.hdfssink-java.hdfs.rollCount=40000
agent.sinks.hdfssink-java.hdfs.batchSize=20000
agent.sinks.hdfssink-java.hdfs.txnEventMax=20000
agent.sinks.hdfssink-java.hdfs.threadsPoolSize=100
agent.sinks.hdfssink-java.hdfs.rollTimerPoolSize=10

【问题讨论】:

    标签: hadoop hdfs flume


    【解决方案1】:

    我在您的配置中看到了一些可能导致问题的东西:

    1. 您的第一个代理似乎有一个批量大小为 1 的 avro 接收器。您应该将其增加到至少 100 或更多。这是因为第二个代理上的 avro 源将提交到批量大小为 1 的通道。每次提交都会导致 fsync,从而导致文件通道性能变差。 exec 源上的批处理大小也是 1,导致该通道也很慢。您可以增加批量大小(或使用假脱机目录源 - 稍后会详细介绍)。

    2. 您可以让多个 HDFS 接收器从同一通道读取数据以提高性能。您应该确保每个接收器写入不同的目录或具有不同的“hdfs.filePrefix”,以便多个 HDFS 接收器不会尝试写入相同的文件。

    3. 您的 HDFS 接收器的批处理大小为 20000,这是相当高的,您的 callTimeout 是默认的 10 秒。如果你想保持如此大的批量大小,你应该增加“hdfs.callTimeout”。我建议将批量大小减少到 1000 左右,并且超时时间约为 15-20 秒。 (请注意,在当前的批量大小下,每个文件只包含 2 个批量 - 所以减少批量大小,增加 rollInterval 和 timeOut)

    如果您使用的是 tail -F,我建议您试用新的 Spool Directory Source。要使用此源,请将您的日志文件轮换到 Spool Directory Source 处理的目录。此源将仅处理不可变的文件,因此您需要轮换日志文件。如 Flume 用户指南中所述,将 tail -F 与 exec 源一起使用存在问题。

    【讨论】:

    • 感谢您的回答和有用的输入!我为这两个来源选择了 1 的 batchSize 的原因是,与我一起工作的系统管理员之一认为他希望日志尽快在 HDFS 中进行分析,并且根据该行等待批处理需要太多时间的推理。我想这是一个有争议的问题,因为 Hadoop 确实是一种面向批处理的技术。我会尝试您的建议并使用设置进行一些操作以获得更好的性能。您是否认为这也可以解决未处理的积压工作(无论如何都足够快)?
    • 关于 Spool Directory Source :rd 听起来很有趣,但我们在集群上运行 CDH4.1.2,它使用 Flume-NG 1.2.0,据我所知没有来源尚未。
    • 看起来 CDH4.1.2 没有假脱机目录源。您应该升级到 CDH4.4 以获得更多功能和稳定性修复。 CDH 通常比它所基于的上游版本有更多的错误修复。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-07-18
    • 2018-09-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-11-27
    • 2019-08-21
    相关资源
    最近更新 更多