前几篇我们一直在拆Flume的Source、Channel、Sink单机版的采集链路已经能跑起来了。但凡是真把Flume用到生产环境的人迟早会遇到一个绕不开的问题下游那个接收端挂了怎么办日志还在源源不断产生数据是会丢、还是会堵在中间另一个场景是量一大一个接收端或者一个HDFS目录扛不住吞吐能不能把流量分摊到多个节点这篇就解决这两个问题也是Flume快速入门系列里非常贴近“高可用”的一篇负载均衡和故障转移。这两个能力其实都藏在Flume的Sink组里配置起来不算复杂但坑不少值得专门写一篇。这篇内容适合两类人看。一类是已经把单Agent跑通、准备把日志从几台服务器汇聚到统一平台的入门开发者另一类是正在设计采集层高可用方案、想搞清楚Sink组内部切换逻辑的运维同学。我会先用一个模拟项目X的场景把概念讲明白再给两套可以直接抄的完整配置最后把我在实际部署中踩过的坑和监控方法一并列出来。1. 负载均衡和故障转移到底在解决什么问题1.1 先还原一个真实场景我在某公司做过一套日志采集系统结构很简单几十台业务服务器上各跑一个Flume Agent把应用日志发给一台中心日志服务器再由中心服务器分拣写入不同目录。前期一切正常后来有一天中心日志服务器磁盘满了所有业务机的Flume都开始报错Channel数据越积越多日志文件在本地不断膨胀最终连业务机器自己的磁盘都差点被打满。这个事故暴露了一个问题单点接收的架构再怎么优化单机性能都躲不过“一个节点挂了拖垮一片”的风险。后来我们改造拓扑增加了一台备用接收节点。但新增的节点怎么让Flume用起来一开始我想到的办法是把业务机的Sink随机指向其中一台但这样每次变更都要改大量配置而且没法自动切换。真正需要的是让Flume自己在多个Sink之间做选择于是Sink组和Sink Processor就派上了用场。1.2 搞清楚这是两个不同的机制负载均衡和故障转移经常被放在一起讲但它们的性质完全不同。负载均衡解决的是“流量怎么分”的问题。多个接收端同时在线每条日志只要发往其中任意一个就算成功目的是水平分摊压力让整个采集链路的总吞吐变大。就好比超市开了多个收银台每个收银台都可以接待顾客。故障转移解决的是“主链路断了怎么办”的问题。它不追求同时使用多条链路而是指定一台优先接收数据只有这台挂了才临时切换到备用节点。主节点恢复后再切回来。这就更像发电机的双路供电平时走主路主路断了自动倒到备路。理解这个差异非常重要因为很多人一看到Sink组就把两个功能混在一起实际选型时容易选错。如果你的目标是提升吞吐、降低单节点压力用负载均衡如果你的目标是保障可用性、不中断数据链路用故障转移。1.3 Flume里这两个功能的载体Sink组Flume的配置模型里一个Channel可以对接多个Sink但如果没有特殊处理多个Sink会各自从同一个Channel里取数据互相竞争行为不可控。为了把多个Sink组织起来Flume提供了Sink组的概念。这里有一组容易混淆的配置项先理清楚a1.sinks定义了这个Agent里所有的Sink它们是“候选者”。a1.sinkgroups把多个Sink放到一个组里并指定组内用哪种Sink Processor。a1.sinkgroups.g1.processor.type决定组内处理器类型可选值就是loadbalance和failover。Sink组的价值在于所有Sink仍然共用同一个Channel但到底由哪个Sink去取数据、取多少由Processor统一调度。数据从Channel到Sink的领取权被Processor管了起来。这样一来多个Sink不再是各自为战而是被编排成了一条带有策略的发送链路。2. 动手前先搭好实验环境拓扑、角色与配置骨架2.1 实验拓扑与角色分工为了把负载均衡和故障转移讲得具体我设计了一个三节点实验环境全部在本机用不同端口模拟也可以Agent A数据生产端也是我们要重点配置的节点。它读取一个本地日志文件通过Sink组把数据同时发往下游。Agent B接收端一监听4141端口。Agent C接收端二监听4142端口。实战中Agent B和Agent C通常是下游的聚合节点或者HDFS写入节点实验里用带loggerSink的接收Agent就够了数据到了之后直接在控制台打印出来方便数条数、看分布。如果你要在同一台机器上做实验记得给每个Agent指定不同的--name和日志级别避免日志输出混在一起。2.2 接收端Agent的配置Agent B和Agent C的配置几乎一样只是监听端口不同。以Agent B为例# agent-b.conf b1.sources src-avro b1.channels ch-mem b1.sinks logger-sink b1.sources.src-avro.type avro b1.sources.src-avro.bind 0.0.0.0 b1.sources.src-avro.port 4141 b1.sources.src-avro.channels ch-mem b1.channels.ch-mem.type memory b1.channels.ch-mem.capacity 10000 b1.channels.ch-mem.transactionCapacity 1000 b1.sinks.logger-sink.type logger b1.sinks.logger-sink.channel ch-memAgent C把端口改成4142就行。为什么接收端要用Avro Source因为Flume的Avro Sink和Avro Source是一对原生协议序列化效率高而且是Flume标准节点之间通信最常用的方式实验环境用它最能反映真实链路的行为。2.3 发送端Agent的Sink组配置骨架Agent A的配置是重头戏。数据源我用exec配合tail -F模拟实时日志读取Channel用内存ChannelSink组里放两个Avro Sink。在配置Sink组之前先看一段不完整的骨架感受一下结构# agent-a.conf 骨架 a1.sources src-tail a1.channels ch-mem a1.sinks k1 k2 a1.sinkgroups g1 a1.sources.src-tail.type exec a1.sources.src-tail.command tail -F /data/logs/app.log a1.sources.src-tail.channels ch-mem a1.channels.ch-mem.type memory a1.channels.ch-mem.capacity 10000 a1.channels.ch-mem.transactionCapacity 1000 a1.sinks.k1.type avro a1.sinks.k1.hostname localhost a1.sinks.k1.port 4141 a1.sinks.k1.channel ch-mem a1.sinks.k2.type avro a1.sinks.k2.hostname localhost a1.sinks.k2.port 4142 a1.sinks.k2.channel ch-mem注意a1.sinks里的名称和sinkgroups里的名称必须完全一致多个名称用空格隔开不要用逗号。这个细节我后面会专门讲因为它是个高频报错点。3. 实战负载均衡配置、启动与效果验证3.1 完整配置与启动步骤在骨架基础上给Agent A加上Sink组配置选择负载均衡策略# agent-a-lb.conf a1.sources src-tail a1.channels ch-mem a1.sinks k1 k2 a1.sinkgroups g1 a1.sources.src-tail.type exec a1.sources.src-tail.command tail -F /data/logs/app.log a1.sources.src-tail.channels ch-mem a1.channels.ch-mem.type memory a1.channels.ch-mem.capacity 10000 a1.channels.ch-mem.transactionCapacity 1000 a1.sinks.k1.type avro a1.sinks.k1.hostname localhost a1.sinks.k1.port 4141 a1.sinks.k1.channel ch-mem a1.sinks.k2.type avro a1.sinks.k2.hostname localhost a1.sinks.k2.port 4142 a1.sinks.k2.channel ch-mem a1.sinkgroups.g1.sinks k1 k2 a1.sinkgroups.g1.processor.type loadbalance a1.sinkgroups.g1.processor.selector round_robin a1.sinkgroups.g1.processor.backoff true配置里有两个容易忽略的细节processor.selector决定选择算法我用的round_robin是轮流发送适合两个接收端处理能力接近的场景如果要更随机或带有权重强需求可以换成random。processor.backoff决定某个Sink在发送失败后是否要进入“惩罚期”设为true后失败的Sink会暂时被跳过避免每次都卡在故障链路上影响效率。启动顺序有讲究。先启动Agent B和Agent C再启动Agent Aflume-ng agent --name b1 --conf-file /opt/flume/conf/agent-b.conf -Dflume.root.loggerINFO,console flume-ng agent --name c1 --conf-file /opt/flume/conf/agent-c.conf -Dflume.root.loggerINFO,console flume-ng agent --name a1 --conf-file /opt/flume/conf/agent-a-lb.conf -Dflume.root.loggerINFO,console为什么要这个顺序因为Avro Sink启动后并不是立即去连目标端口而是边处理事件边建立连接如果接收端没起来Sink会持续重试。先启动接收端能让Agent A启动后短时间内就建立好两条链路便于我们观察轮询效果。3.2 写入测试数据并观察分流结果Agent A读的是/data/logs/app.log我们用脚本往里面写入100条测试日志for i in $(seq 1 100); do echo test-$i $(date %F %T) /data/logs/app.log sleep 0.1 done每写入一条Agent A的tail命令会感知到文件新增内容将每一行包装成一个Flume事件送入ChannelSink组里的轮询处理器再依次分配给k1和k2。正常情况下Agent B和Agent C的控制台会各打印大约50条日志。如果去看Agent B和Agent C的EventDrainSuccessCount指标两条链路的成功计数也会非常接近。这里有个非常实用的验证技巧如果嫌数控制台日志太费劲可以给每个Agent开启Flume的HTTP监控-Dflume.monitoring.typehttp -Dflume.monitoring.port34546然后请求http://localhost:34546/metrics能看到每个Sink的EventDrainSuccessCount、每个Channel的ChannelFillPercentage直接拿着数字判断均衡效果比肉眼数日志靠谱得多。3.3 把一个接收端停掉看看会发生什么负载均衡模式下的故障表现值得单独说。我们把Agent B整个停掉然后继续往app.log写数据。观察Agent A这边的行为它不会傻到继续把一半数据往已经断掉的4141端口发因为backofftrue时失败的Sink会被临时拉黑。实际表现是Agent A会先尝试把一条事件发给k1发现连接失败于是这条事件被放回Channel处理器把k1标记为“不健康”接下来的一段时间只从k2发送。要注意这个“只从k2发送”不是故障转移意义上的“切换”而是负载均衡器在剔除失败节点等惩罚期结束后k1会被重新试探。如果你把backoff设为false表现会完全不同每次轮询到k1时都会硬着头皮尝试连接每次都要等超时整体吞吐会明显下降。所以我在生产环境中强烈建议把backoff打开。再往下做一些实验把Agent B重新启动等到惩罚期结束你会发现k1自动恢复接单不需要重启Agent A也不需要改配置。这说明负载均衡模式下本身就带有一定程度的“故障感知能力”只是它的首要目标依然是分流而不是严格的主备切换。4. 实战故障转移配置、启动与效果验证4.1 故障转移的完整配置故障转移模式的定位是完全不同的。它要求我们明确指定谁优先、谁备用数据在正常情况下只走主节点。把Agent A的Sink组配置改一下# agent-a-fo.conf a1.sources src-tail a1.channels ch-mem a1.sinks k1 k2 a1.sinkgroups g1 a1.sources.src-tail.type exec a1.sources.src-tail.command tail -F /data/logs/app.log a1.sources.src-tail.channels ch-mem a1.channels.ch-mem.type memory a1.channels.ch-mem.capacity 10000 a1.channels.ch-mem.transactionCapacity 1000 a1.sinks.k1.type avro a1.sinks.k1.hostname localhost a1.sinks.k1.port 4141 a1.sinks.k1.channel ch-mem a1.sinks.k2.type avro a1.sinks.k2.hostname localhost a1.sinks.k2.port 4142 a1.sinks.k2.channel ch-mem a1.sinkgroups.g1.sinks k1 k2 a1.sinkgroups.g1.processor.type failover a1.sinkgroups.g1.processor.priority.k1 10 a1.sinkgroups.g1.processor.priority.k2 5 a1.sinkgroups.g1.processor.maxpenalty 20000关键参数是processor.priority.k1和processor.priority.k2。很多人第一次配的时候容易记反以为数字越小越优先。实际上Flume的规则是数字越大优先级越高。k1的优先级是10k2是5所以k1是主Sinkk2是备Sink。processor.maxpenalty控制的是失败后的最大惩罚时间单位毫秒。默认值是30000也就是主Sink挂了之后要等30秒才有机会被重新试探。实验环境里为了演示切换速度我把它调成了20秒。4.2 验证主备切换的完整过程按照同样的顺序启动三个Agent然后向app.log写入数据。你会看到Agent B的控制台一直在刷日志Agent C的控制台没有任何输出。这说明故障转移模式和负载均衡的第一个直观区别正常情况下备用节点是闲置的流量不会自动分摊。接下来模拟主节点故障。杀掉Agent B的Flume进程注意是直接杀掉接收端进程而不是只断开端口。然后继续写入几条测试日志观察Agent A的控制台输出。可以看到Agent A并不会立刻把数据切向k2而是先尝试把事件发给k1发现连接失败后Sink处理器给k1打上失败标记并进入惩罚期随后转向k2。所以实际表现是中间可能有几秒的发送等待之后Agent C开始收到数据。这里要提醒一下故障转移的“切换时间”从来都不是零。它取决于连接超时时间、重试间隔和maxpenalty。如果你的应用对日志实时性要求很高可以适当调小maxpenalty但调太小会导致主节点抖动时频繁切换反而制造不稳定。主节点恢复后的行为也值得观察重启Agent B继续写数据。由于k1的优先级最高当惩罚期结束后Sink处理器会优先尝试k1一旦连接成功流量会自动切回k1k2再次进入闲置状态。整个过程不需要人工干预也不需要重启Agent A。4.3 数据会不会丢事务机制与Channel的角色很多人会问一个关键问题故障转移期间Channel里的数据会不会丢答案是正常情况下不会丢。Flume的Channel是带事务的Sink从Channel取出一批事件后要等这批事件成功发送到下游事务才算提交如果下游连接失败这批事件会回滚到Channel里由下一个可用的Sink重新读取。这个机制保证了数据在Flume内部链路上的不丢失。但有两个前提需要特别注意。第一Channel的容量必须足够大如果主节点故障期间数据持续写入但备节点切换不及时Channel塞满后Source就会停止读取日志文件表现为日志处理滞后。第二如果你用的是exec这种没有断点续传能力的Source进程异常重启后tail命令会从头开始读文件导致重复数据。所以生产环境里我通常建议大数据量场景把内存Channel换成File Channel或Kafka Channel容量有保障。数据源尽量不要用exectail -F优先用Taildir Source它记录文件偏移重启后能续读。5. 生产环境常见的5个坑与排查思路5.1 Sink组配置不生效我见过最多的情况是配置里写了sinkgroups但日志显示只有一个Sink在工作或者数据直接不发送。排查第一步是检查Sink名称a1.sinks k1 k2里使用的名称必须和sinkgroups.g1.sinks k1 k2里的名称、以及a1.sinks.k1.*的前缀完全一致。第二是分隔符。sinkgroups.g1.sinks的值是空格分隔的Sink名称列表不是逗号。写成逗号处理器解析的时候会把整个字符串当成一个名字找不到对应的Sink配置直接报错。第三是处理器类名。processor.type的值是loadbalance和failover区分大小写写错了不会立即报错但会fallback到默认的FailoverProcessor或直接启动失败日志里能看到相关异常。5.2 负载严重不均如果配置了round_robin但长时间观察下来一边收到的数据明显更多先不要怀疑轮询算法有问题。常见原因有两个第一个原因是selector写成了random。随机算法在短时间段内天然有波动如果写入频率不高比如每秒只有几条连续随机到同一节点几轮也正常。第二个原因是backoff惩罚机制导致的“假性倾斜”。某个接收端曾经抖动过被标记为不健康进入惩罚期后流量自然全走另一个节点惩罚期结束才会恢复。如果接收端性能差距大慢的节点经常超时这种倾斜会持续存在。处理办法是先解决接收端性能问题再根据实际吞吐决定要不要在顶层加一层负载均衡。5.3 故障转移不切换或切不回来故障转移配置了主节点也停了但数据没有切到备用节点。先检查优先级写没写对processor.priority.k1 10里的数字越大越优先不是越小越优先。如果你把主节点配成5备用节点配成10备用节点反而成了主节点。然后是Sink的目标地址问题。我见过一种情况k1和k2的配置是从同一个模板复制出来的hostname和port没有改完两个Sink实际上指向同一个地址。主节点故障时k1和k2同时失败备用节点永远接不到数据。如果主节点恢复后一直切不回来多半是maxpenalty设得太大主节点还在惩罚期内。另外注意Flume的故障转移恢复不是“秒回”它会等惩罚期结束后重新尝试最高优先级Sink连接成功后才会切回整个过程比想象的要慢一些是正常的。5.4 切换期间数据堆积故障转移生效后数据倒是没丢但堆积了很多。这时候先看Channel的ChannelFillPercentage如果长期接近100%说明Channel容量不够。此时即便故障转移瞬时完成了上游Source也已经被“反压”停掉过日志处理出现了缺口。解决办法有几个层次短期可以增大capacity和transactionCapacity中期可以把内存Channel换成分层存储的File Channel更彻底的做法是在采集端和聚合端之间加一层消息队列用Kafka Channel充当缓冲让Flume的Sink组只管最终写盘缓冲区交给更可靠的外部组件。这不是Flume本身不够好而是高吞吐场景下内存缓冲天然扛不住长时间故障。5.5 监控指标怎么看如果不看指标全靠日志判断链路状态排障效率会非常低。我给三个最重要的指标EventDrainSuccessCountSink成功发送事件数两个Sink的数值差能直观反映负载分布。EventDrainAttemptCountSink尝试发送总次数如果远大于成功次数说明这条链路在不断重试。ChannelFillPercentageChannel使用率长期超过80%就要警惕容量或下游吞吐问题。在Flume启动参数里加上HTTP监控参数然后定期采集/metrics接口就行了。采集层写个简单的脚本出现异常时告警这比等到日志文件堆积才发现问题要省心得多。下面把常见问题整理成速查表问题现象常见原因处理方式数据只走一个SinkSink名称不一致、优先级配反检查名称和priority数字大小负载明显偏斜随机算法、backoff拉黑、接收端性能差异改用round_robin排查接收端抖动故障后切不过去优先级配反、Sink指向同一地址核对配置确认两个目标是不同实例恢复很慢maxpenalty过大按业务容忍度调小惩罚时间故障期间数据堆积Channel容量不足换File/Kafka Channel或增大容量Sink组配置报错名称拼写错误、逗号分隔、类名大小写逐项检查用空格分隔名称6. 参数调优与容量估算参考6.1 三个必须搞懂的关键参数processor.backoff在负载均衡模式下非常关键建议设为true。注意它的行为不是“失败一次永久拉黑”而是进入一个惩罚期惩罚期的退避策略在不同版本里略有差异整体上是逐步增加的给了故障节点恢复的机会。processor.maxpenalty主要影响故障转移模式的恢复速度。默认30秒对很多场景偏保守可以结合业务的容忍度调到10到20秒但不建议低于5秒否则主节点网络抖动一次流量就会在两条链路之间来回跳。transactionCapacity和capacity的关系一定要清楚。transactionCapacity是单次事务最多处理的批事件数capacity是整个Channel的容量。capacity必须不小于transactionCapacity实践中建议transactionCapacity约为capacity的十分之一例如capacity10000、transactionCapacity1000。Sink的batchSize最好和transactionCapacity接近避免频繁提交事务。6.2 一个容量估算的简单例子假设某业务系统每秒产生500条日志正常情况下Sink组能把它们全部发出去。现在主节点故障了从故障发生到故障转移完成、再到备节点稳定写入大约需要2分钟。那么Channel里最多可能堆积的数据量是500条/秒 × 120秒 60000条内存Channel的capacity至少要设到60000以上再加上安全余量建议设成80000到100000。如果不确定单条事件大小还要估算内存占用。每条Flume事件除了日志正文还包含headers、长度信息等开销单条按1KB估算的话10万条大约占用100MB内存在实际部署中是完全可以接受的。如果故障时长是10分钟哪怕只有200条/秒堆积量也是12万条这样内存Channel就变得危险了。这时候应该考虑File Channel或者外接消息队列而不是无限加大内存。6.3 多级架构中的选型建议用一个简单的例子说明如果你有几十台业务机要把日志汇总到集群里建议把架构拆成两层。业务机上跑轻量Agent用故障转移把数据发给两到三台汇聚节点汇聚节点再统一写入HDFS或消息队列。业务层和汇聚层之间采用负载均衡汇聚层和存储层之间再视存储组件能力决定是否继续分流。实际部署中我发现很多人误以为负载均衡和故障转移必须二选一其实它们是不同层级的工具。上层和下层面临的风险不同选型诉求也不同。举个例子业务机到汇聚节点我们关心链路不能断所以用故障转移汇聚层如果不止一台业务机可以用负载均衡把流量分散到多台汇聚节点再靠汇聚节点内部的高可用机制保证最终写出。架构清晰之后每一层用哪个模式答案就自然出来了。最后说一下我自己在实际项目里的体会。Flume的Sink组是实现采集高可用最直接的手段配置不难真正难的是理解它背后的失败模型和恢复模型。我踩过最大的坑就是把负载均衡当成高可用方案用结果其中一个接收端持续抖动时数据被大量退回Channel最后靠加大容量才撑着没丢。后来把所有核心链路改成故障转移模式才真正解决了“主节点恢复后自动回切”的问题。如果你也要搭生产级日志采集链路建议从最小三节点拓扑开始把这篇里的两个实验完整跑一遍亲眼看看切换日志和数据分布再上线不迟。
前几篇我们一直在拆Flume的Source、Channel、Sink单机版的采集链路已经能跑起来了。但凡是真把Flume用到生产环境的人迟早会遇到一个绕不开的问题下游那个接收端挂了怎么办日志还在源源不断产生数据是会丢、还是会堵在中间另一个场景是量一大一个接收端或者一个HDFS目录扛不住吞吐能不能把流量分摊到多个节点这篇就解决这两个问题也是Flume快速入门系列里非常贴近“高可用”的一篇负载均衡和故障转移。这两个能力其实都藏在Flume的Sink组里配置起来不算复杂但坑不少值得专门写一篇。这篇内容适合两类人看。一类是已经把单Agent跑通、准备把日志从几台服务器汇聚到统一平台的入门开发者另一类是正在设计采集层高可用方案、想搞清楚Sink组内部切换逻辑的运维同学。我会先用一个模拟项目X的场景把概念讲明白再给两套可以直接抄的完整配置最后把我在实际部署中踩过的坑和监控方法一并列出来。1. 负载均衡和故障转移到底在解决什么问题1.1 先还原一个真实场景我在某公司做过一套日志采集系统结构很简单几十台业务服务器上各跑一个Flume Agent把应用日志发给一台中心日志服务器再由中心服务器分拣写入不同目录。前期一切正常后来有一天中心日志服务器磁盘满了所有业务机的Flume都开始报错Channel数据越积越多日志文件在本地不断膨胀最终连业务机器自己的磁盘都差点被打满。这个事故暴露了一个问题单点接收的架构再怎么优化单机性能都躲不过“一个节点挂了拖垮一片”的风险。后来我们改造拓扑增加了一台备用接收节点。但新增的节点怎么让Flume用起来一开始我想到的办法是把业务机的Sink随机指向其中一台但这样每次变更都要改大量配置而且没法自动切换。真正需要的是让Flume自己在多个Sink之间做选择于是Sink组和Sink Processor就派上了用场。1.2 搞清楚这是两个不同的机制负载均衡和故障转移经常被放在一起讲但它们的性质完全不同。负载均衡解决的是“流量怎么分”的问题。多个接收端同时在线每条日志只要发往其中任意一个就算成功目的是水平分摊压力让整个采集链路的总吞吐变大。就好比超市开了多个收银台每个收银台都可以接待顾客。故障转移解决的是“主链路断了怎么办”的问题。它不追求同时使用多条链路而是指定一台优先接收数据只有这台挂了才临时切换到备用节点。主节点恢复后再切回来。这就更像发电机的双路供电平时走主路主路断了自动倒到备路。理解这个差异非常重要因为很多人一看到Sink组就把两个功能混在一起实际选型时容易选错。如果你的目标是提升吞吐、降低单节点压力用负载均衡如果你的目标是保障可用性、不中断数据链路用故障转移。1.3 Flume里这两个功能的载体Sink组Flume的配置模型里一个Channel可以对接多个Sink但如果没有特殊处理多个Sink会各自从同一个Channel里取数据互相竞争行为不可控。为了把多个Sink组织起来Flume提供了Sink组的概念。这里有一组容易混淆的配置项先理清楚a1.sinks定义了这个Agent里所有的Sink它们是“候选者”。a1.sinkgroups把多个Sink放到一个组里并指定组内用哪种Sink Processor。a1.sinkgroups.g1.processor.type决定组内处理器类型可选值就是loadbalance和failover。Sink组的价值在于所有Sink仍然共用同一个Channel但到底由哪个Sink去取数据、取多少由Processor统一调度。数据从Channel到Sink的领取权被Processor管了起来。这样一来多个Sink不再是各自为战而是被编排成了一条带有策略的发送链路。2. 动手前先搭好实验环境拓扑、角色与配置骨架2.1 实验拓扑与角色分工为了把负载均衡和故障转移讲得具体我设计了一个三节点实验环境全部在本机用不同端口模拟也可以Agent A数据生产端也是我们要重点配置的节点。它读取一个本地日志文件通过Sink组把数据同时发往下游。Agent B接收端一监听4141端口。Agent C接收端二监听4142端口。实战中Agent B和Agent C通常是下游的聚合节点或者HDFS写入节点实验里用带loggerSink的接收Agent就够了数据到了之后直接在控制台打印出来方便数条数、看分布。如果你要在同一台机器上做实验记得给每个Agent指定不同的--name和日志级别避免日志输出混在一起。2.2 接收端Agent的配置Agent B和Agent C的配置几乎一样只是监听端口不同。以Agent B为例# agent-b.conf b1.sources src-avro b1.channels ch-mem b1.sinks logger-sink b1.sources.src-avro.type avro b1.sources.src-avro.bind 0.0.0.0 b1.sources.src-avro.port 4141 b1.sources.src-avro.channels ch-mem b1.channels.ch-mem.type memory b1.channels.ch-mem.capacity 10000 b1.channels.ch-mem.transactionCapacity 1000 b1.sinks.logger-sink.type logger b1.sinks.logger-sink.channel ch-memAgent C把端口改成4142就行。为什么接收端要用Avro Source因为Flume的Avro Sink和Avro Source是一对原生协议序列化效率高而且是Flume标准节点之间通信最常用的方式实验环境用它最能反映真实链路的行为。2.3 发送端Agent的Sink组配置骨架Agent A的配置是重头戏。数据源我用exec配合tail -F模拟实时日志读取Channel用内存ChannelSink组里放两个Avro Sink。在配置Sink组之前先看一段不完整的骨架感受一下结构# agent-a.conf 骨架 a1.sources src-tail a1.channels ch-mem a1.sinks k1 k2 a1.sinkgroups g1 a1.sources.src-tail.type exec a1.sources.src-tail.command tail -F /data/logs/app.log a1.sources.src-tail.channels ch-mem a1.channels.ch-mem.type memory a1.channels.ch-mem.capacity 10000 a1.channels.ch-mem.transactionCapacity 1000 a1.sinks.k1.type avro a1.sinks.k1.hostname localhost a1.sinks.k1.port 4141 a1.sinks.k1.channel ch-mem a1.sinks.k2.type avro a1.sinks.k2.hostname localhost a1.sinks.k2.port 4142 a1.sinks.k2.channel ch-mem注意a1.sinks里的名称和sinkgroups里的名称必须完全一致多个名称用空格隔开不要用逗号。这个细节我后面会专门讲因为它是个高频报错点。3. 实战负载均衡配置、启动与效果验证3.1 完整配置与启动步骤在骨架基础上给Agent A加上Sink组配置选择负载均衡策略# agent-a-lb.conf a1.sources src-tail a1.channels ch-mem a1.sinks k1 k2 a1.sinkgroups g1 a1.sources.src-tail.type exec a1.sources.src-tail.command tail -F /data/logs/app.log a1.sources.src-tail.channels ch-mem a1.channels.ch-mem.type memory a1.channels.ch-mem.capacity 10000 a1.channels.ch-mem.transactionCapacity 1000 a1.sinks.k1.type avro a1.sinks.k1.hostname localhost a1.sinks.k1.port 4141 a1.sinks.k1.channel ch-mem a1.sinks.k2.type avro a1.sinks.k2.hostname localhost a1.sinks.k2.port 4142 a1.sinks.k2.channel ch-mem a1.sinkgroups.g1.sinks k1 k2 a1.sinkgroups.g1.processor.type loadbalance a1.sinkgroups.g1.processor.selector round_robin a1.sinkgroups.g1.processor.backoff true配置里有两个容易忽略的细节processor.selector决定选择算法我用的round_robin是轮流发送适合两个接收端处理能力接近的场景如果要更随机或带有权重强需求可以换成random。processor.backoff决定某个Sink在发送失败后是否要进入“惩罚期”设为true后失败的Sink会暂时被跳过避免每次都卡在故障链路上影响效率。启动顺序有讲究。先启动Agent B和Agent C再启动Agent Aflume-ng agent --name b1 --conf-file /opt/flume/conf/agent-b.conf -Dflume.root.loggerINFO,console flume-ng agent --name c1 --conf-file /opt/flume/conf/agent-c.conf -Dflume.root.loggerINFO,console flume-ng agent --name a1 --conf-file /opt/flume/conf/agent-a-lb.conf -Dflume.root.loggerINFO,console为什么要这个顺序因为Avro Sink启动后并不是立即去连目标端口而是边处理事件边建立连接如果接收端没起来Sink会持续重试。先启动接收端能让Agent A启动后短时间内就建立好两条链路便于我们观察轮询效果。3.2 写入测试数据并观察分流结果Agent A读的是/data/logs/app.log我们用脚本往里面写入100条测试日志for i in $(seq 1 100); do echo test-$i $(date %F %T) /data/logs/app.log sleep 0.1 done每写入一条Agent A的tail命令会感知到文件新增内容将每一行包装成一个Flume事件送入ChannelSink组里的轮询处理器再依次分配给k1和k2。正常情况下Agent B和Agent C的控制台会各打印大约50条日志。如果去看Agent B和Agent C的EventDrainSuccessCount指标两条链路的成功计数也会非常接近。这里有个非常实用的验证技巧如果嫌数控制台日志太费劲可以给每个Agent开启Flume的HTTP监控-Dflume.monitoring.typehttp -Dflume.monitoring.port34546然后请求http://localhost:34546/metrics能看到每个Sink的EventDrainSuccessCount、每个Channel的ChannelFillPercentage直接拿着数字判断均衡效果比肉眼数日志靠谱得多。3.3 把一个接收端停掉看看会发生什么负载均衡模式下的故障表现值得单独说。我们把Agent B整个停掉然后继续往app.log写数据。观察Agent A这边的行为它不会傻到继续把一半数据往已经断掉的4141端口发因为backofftrue时失败的Sink会被临时拉黑。实际表现是Agent A会先尝试把一条事件发给k1发现连接失败于是这条事件被放回Channel处理器把k1标记为“不健康”接下来的一段时间只从k2发送。要注意这个“只从k2发送”不是故障转移意义上的“切换”而是负载均衡器在剔除失败节点等惩罚期结束后k1会被重新试探。如果你把backoff设为false表现会完全不同每次轮询到k1时都会硬着头皮尝试连接每次都要等超时整体吞吐会明显下降。所以我在生产环境中强烈建议把backoff打开。再往下做一些实验把Agent B重新启动等到惩罚期结束你会发现k1自动恢复接单不需要重启Agent A也不需要改配置。这说明负载均衡模式下本身就带有一定程度的“故障感知能力”只是它的首要目标依然是分流而不是严格的主备切换。4. 实战故障转移配置、启动与效果验证4.1 故障转移的完整配置故障转移模式的定位是完全不同的。它要求我们明确指定谁优先、谁备用数据在正常情况下只走主节点。把Agent A的Sink组配置改一下# agent-a-fo.conf a1.sources src-tail a1.channels ch-mem a1.sinks k1 k2 a1.sinkgroups g1 a1.sources.src-tail.type exec a1.sources.src-tail.command tail -F /data/logs/app.log a1.sources.src-tail.channels ch-mem a1.channels.ch-mem.type memory a1.channels.ch-mem.capacity 10000 a1.channels.ch-mem.transactionCapacity 1000 a1.sinks.k1.type avro a1.sinks.k1.hostname localhost a1.sinks.k1.port 4141 a1.sinks.k1.channel ch-mem a1.sinks.k2.type avro a1.sinks.k2.hostname localhost a1.sinks.k2.port 4142 a1.sinks.k2.channel ch-mem a1.sinkgroups.g1.sinks k1 k2 a1.sinkgroups.g1.processor.type failover a1.sinkgroups.g1.processor.priority.k1 10 a1.sinkgroups.g1.processor.priority.k2 5 a1.sinkgroups.g1.processor.maxpenalty 20000关键参数是processor.priority.k1和processor.priority.k2。很多人第一次配的时候容易记反以为数字越小越优先。实际上Flume的规则是数字越大优先级越高。k1的优先级是10k2是5所以k1是主Sinkk2是备Sink。processor.maxpenalty控制的是失败后的最大惩罚时间单位毫秒。默认值是30000也就是主Sink挂了之后要等30秒才有机会被重新试探。实验环境里为了演示切换速度我把它调成了20秒。4.2 验证主备切换的完整过程按照同样的顺序启动三个Agent然后向app.log写入数据。你会看到Agent B的控制台一直在刷日志Agent C的控制台没有任何输出。这说明故障转移模式和负载均衡的第一个直观区别正常情况下备用节点是闲置的流量不会自动分摊。接下来模拟主节点故障。杀掉Agent B的Flume进程注意是直接杀掉接收端进程而不是只断开端口。然后继续写入几条测试日志观察Agent A的控制台输出。可以看到Agent A并不会立刻把数据切向k2而是先尝试把事件发给k1发现连接失败后Sink处理器给k1打上失败标记并进入惩罚期随后转向k2。所以实际表现是中间可能有几秒的发送等待之后Agent C开始收到数据。这里要提醒一下故障转移的“切换时间”从来都不是零。它取决于连接超时时间、重试间隔和maxpenalty。如果你的应用对日志实时性要求很高可以适当调小maxpenalty但调太小会导致主节点抖动时频繁切换反而制造不稳定。主节点恢复后的行为也值得观察重启Agent B继续写数据。由于k1的优先级最高当惩罚期结束后Sink处理器会优先尝试k1一旦连接成功流量会自动切回k1k2再次进入闲置状态。整个过程不需要人工干预也不需要重启Agent A。4.3 数据会不会丢事务机制与Channel的角色很多人会问一个关键问题故障转移期间Channel里的数据会不会丢答案是正常情况下不会丢。Flume的Channel是带事务的Sink从Channel取出一批事件后要等这批事件成功发送到下游事务才算提交如果下游连接失败这批事件会回滚到Channel里由下一个可用的Sink重新读取。这个机制保证了数据在Flume内部链路上的不丢失。但有两个前提需要特别注意。第一Channel的容量必须足够大如果主节点故障期间数据持续写入但备节点切换不及时Channel塞满后Source就会停止读取日志文件表现为日志处理滞后。第二如果你用的是exec这种没有断点续传能力的Source进程异常重启后tail命令会从头开始读文件导致重复数据。所以生产环境里我通常建议大数据量场景把内存Channel换成File Channel或Kafka Channel容量有保障。数据源尽量不要用exectail -F优先用Taildir Source它记录文件偏移重启后能续读。5. 生产环境常见的5个坑与排查思路5.1 Sink组配置不生效我见过最多的情况是配置里写了sinkgroups但日志显示只有一个Sink在工作或者数据直接不发送。排查第一步是检查Sink名称a1.sinks k1 k2里使用的名称必须和sinkgroups.g1.sinks k1 k2里的名称、以及a1.sinks.k1.*的前缀完全一致。第二是分隔符。sinkgroups.g1.sinks的值是空格分隔的Sink名称列表不是逗号。写成逗号处理器解析的时候会把整个字符串当成一个名字找不到对应的Sink配置直接报错。第三是处理器类名。processor.type的值是loadbalance和failover区分大小写写错了不会立即报错但会fallback到默认的FailoverProcessor或直接启动失败日志里能看到相关异常。5.2 负载严重不均如果配置了round_robin但长时间观察下来一边收到的数据明显更多先不要怀疑轮询算法有问题。常见原因有两个第一个原因是selector写成了random。随机算法在短时间段内天然有波动如果写入频率不高比如每秒只有几条连续随机到同一节点几轮也正常。第二个原因是backoff惩罚机制导致的“假性倾斜”。某个接收端曾经抖动过被标记为不健康进入惩罚期后流量自然全走另一个节点惩罚期结束才会恢复。如果接收端性能差距大慢的节点经常超时这种倾斜会持续存在。处理办法是先解决接收端性能问题再根据实际吞吐决定要不要在顶层加一层负载均衡。5.3 故障转移不切换或切不回来故障转移配置了主节点也停了但数据没有切到备用节点。先检查优先级写没写对processor.priority.k1 10里的数字越大越优先不是越小越优先。如果你把主节点配成5备用节点配成10备用节点反而成了主节点。然后是Sink的目标地址问题。我见过一种情况k1和k2的配置是从同一个模板复制出来的hostname和port没有改完两个Sink实际上指向同一个地址。主节点故障时k1和k2同时失败备用节点永远接不到数据。如果主节点恢复后一直切不回来多半是maxpenalty设得太大主节点还在惩罚期内。另外注意Flume的故障转移恢复不是“秒回”它会等惩罚期结束后重新尝试最高优先级Sink连接成功后才会切回整个过程比想象的要慢一些是正常的。5.4 切换期间数据堆积故障转移生效后数据倒是没丢但堆积了很多。这时候先看Channel的ChannelFillPercentage如果长期接近100%说明Channel容量不够。此时即便故障转移瞬时完成了上游Source也已经被“反压”停掉过日志处理出现了缺口。解决办法有几个层次短期可以增大capacity和transactionCapacity中期可以把内存Channel换成分层存储的File Channel更彻底的做法是在采集端和聚合端之间加一层消息队列用Kafka Channel充当缓冲让Flume的Sink组只管最终写盘缓冲区交给更可靠的外部组件。这不是Flume本身不够好而是高吞吐场景下内存缓冲天然扛不住长时间故障。5.5 监控指标怎么看如果不看指标全靠日志判断链路状态排障效率会非常低。我给三个最重要的指标EventDrainSuccessCountSink成功发送事件数两个Sink的数值差能直观反映负载分布。EventDrainAttemptCountSink尝试发送总次数如果远大于成功次数说明这条链路在不断重试。ChannelFillPercentageChannel使用率长期超过80%就要警惕容量或下游吞吐问题。在Flume启动参数里加上HTTP监控参数然后定期采集/metrics接口就行了。采集层写个简单的脚本出现异常时告警这比等到日志文件堆积才发现问题要省心得多。下面把常见问题整理成速查表问题现象常见原因处理方式数据只走一个SinkSink名称不一致、优先级配反检查名称和priority数字大小负载明显偏斜随机算法、backoff拉黑、接收端性能差异改用round_robin排查接收端抖动故障后切不过去优先级配反、Sink指向同一地址核对配置确认两个目标是不同实例恢复很慢maxpenalty过大按业务容忍度调小惩罚时间故障期间数据堆积Channel容量不足换File/Kafka Channel或增大容量Sink组配置报错名称拼写错误、逗号分隔、类名大小写逐项检查用空格分隔名称6. 参数调优与容量估算参考6.1 三个必须搞懂的关键参数processor.backoff在负载均衡模式下非常关键建议设为true。注意它的行为不是“失败一次永久拉黑”而是进入一个惩罚期惩罚期的退避策略在不同版本里略有差异整体上是逐步增加的给了故障节点恢复的机会。processor.maxpenalty主要影响故障转移模式的恢复速度。默认30秒对很多场景偏保守可以结合业务的容忍度调到10到20秒但不建议低于5秒否则主节点网络抖动一次流量就会在两条链路之间来回跳。transactionCapacity和capacity的关系一定要清楚。transactionCapacity是单次事务最多处理的批事件数capacity是整个Channel的容量。capacity必须不小于transactionCapacity实践中建议transactionCapacity约为capacity的十分之一例如capacity10000、transactionCapacity1000。Sink的batchSize最好和transactionCapacity接近避免频繁提交事务。6.2 一个容量估算的简单例子假设某业务系统每秒产生500条日志正常情况下Sink组能把它们全部发出去。现在主节点故障了从故障发生到故障转移完成、再到备节点稳定写入大约需要2分钟。那么Channel里最多可能堆积的数据量是500条/秒 × 120秒 60000条内存Channel的capacity至少要设到60000以上再加上安全余量建议设成80000到100000。如果不确定单条事件大小还要估算内存占用。每条Flume事件除了日志正文还包含headers、长度信息等开销单条按1KB估算的话10万条大约占用100MB内存在实际部署中是完全可以接受的。如果故障时长是10分钟哪怕只有200条/秒堆积量也是12万条这样内存Channel就变得危险了。这时候应该考虑File Channel或者外接消息队列而不是无限加大内存。6.3 多级架构中的选型建议用一个简单的例子说明如果你有几十台业务机要把日志汇总到集群里建议把架构拆成两层。业务机上跑轻量Agent用故障转移把数据发给两到三台汇聚节点汇聚节点再统一写入HDFS或消息队列。业务层和汇聚层之间采用负载均衡汇聚层和存储层之间再视存储组件能力决定是否继续分流。实际部署中我发现很多人误以为负载均衡和故障转移必须二选一其实它们是不同层级的工具。上层和下层面临的风险不同选型诉求也不同。举个例子业务机到汇聚节点我们关心链路不能断所以用故障转移汇聚层如果不止一台业务机可以用负载均衡把流量分散到多台汇聚节点再靠汇聚节点内部的高可用机制保证最终写出。架构清晰之后每一层用哪个模式答案就自然出来了。最后说一下我自己在实际项目里的体会。Flume的Sink组是实现采集高可用最直接的手段配置不难真正难的是理解它背后的失败模型和恢复模型。我踩过最大的坑就是把负载均衡当成高可用方案用结果其中一个接收端持续抖动时数据被大量退回Channel最后靠加大容量才撑着没丢。后来把所有核心链路改成故障转移模式才真正解决了“主节点恢复后自动回切”的问题。如果你也要搭生产级日志采集链路建议从最小三节点拓扑开始把这篇里的两个实验完整跑一遍亲眼看看切换日志和数据分布再上线不迟。
