一.Failover Sink Processor测试
官网解释Failover Sink Processor:
Failover Sink Processor维护一个按优先级排列的sink列表,确保只要有一个sink可用,事件就会被处理(交付)。
Failover机制的工作原理是将失败的接收转移到池中,在池中为它们分配一个冷却期,在重新尝试它们之前,随着顺序故障的增加而增加。一旦接收器成功地发送了一个事件,它就会被恢复到活动池。sink有一个与它们相关联的优先级,数量越大,优先级越高。如果一个接收器在发送事件时失败,下一个具有最高优先级的接收器将被尝试下一步发送事件。例如,优先级为100的接收器在优先级为80的接收器之前被激活。如果没有指定优先级,则thr优先级根据配置中指定的sink的顺序确定。
要进行配置,将sink组处理器设置为Failover,并为所有单个的sink设置优先级。所有指定的优先级必须是唯一的。此外,可以使用maxpenalty属性设置Failover时间的上限(以毫秒为单位)。
下图中44446的优先级更高:
左边agent的配置failover.conf:
a1.sources = r1
a1.channels = c1
a1.sinks = k1 k2
a1.sources.r1.type = netcat
a1.sources.r1.bind = 0.0.0.0
a1.sources.r1.port = 44444
a1.channels.c1.type = memory
a1.sinkgroups = g1
a1.sinkgroups.g1.sinks = k1 k2
a1.sinkgroups.g1.processor.type = failover
a1.sinkgroups.g1.processor.priority.k1 = 5
a1.sinkgroups.g1.processor.priority.k2 = 10
a1.sinkgroups.g1.processor.maxpenalty = 10000
a1.sinks.k1.type = avro
a1.sinks.k1.hostname = hadoop000
a1.sinks.k1.port = 44445
a1.sinks.k2.type = avro
a1.sinks.k2.hostname = hadoop000
a1.sinks.k2.port = 44446
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1
a1.sinks.k2.channel = c1
k2即agent1的44446端口的优先级高(数字越大优先级越高)。
发送数据:
[hadoop@hadoop000 apache-flume-1.6.0-cdh5.15.1-bin]$ telnet localhost 44444
Trying 192.168.198.128...
Connected to localhost.
Escape character is '^]'.
aaa
OK
bbb
OK
ccc
OK
ddd
OK
eee
OK
fff
OK
44446接收到信息:
21/01/25 18:14:47 INFO ipc.NettyServer: [id: 0x0ce2a19e, /192.168.198.128:45240 => /192.168.198.128:44446] OPEN
21/01/25 18:14:47 INFO ipc.NettyServer: [id: 0x0ce2a19e, /192.168.198.128:45240 => /192.168.198.128:44446] BOUND: /192.168.198.128:44446
21/01/25 18:14:47 INFO ipc.NettyServer: [id: 0x0ce2a19e, /192.168.198.128:45240 => /192.168.198.128:44446] CONNECTED: /192.168.198.128:45240
21/01/25 18:15:40 INFO sink.LoggerSink: Event: { headers:{} body: 61 61 61 0D aaa. }
21/01/25 18:16:11 INFO sink.LoggerSink: Event: { headers:{} body: 62 62 62 0D bbb. }
将agent3 kill掉,44445端口被激活:
21/01/25 18:14:46 INFO ipc.NettyServer: [id: 0x946f8c34, /192.168.198.128:55142 => /192.168.198.128:44445] OPEN
21/01/25 18:14:46 INFO ipc.NettyServer: [id: 0x946f8c34, /192.168.198.128:55142 => /192.168.198.128:44445] BOUND: /192.168.198.128:44445
21/01/25 18:14:46 INFO ipc.NettyServer: [id: 0x946f8c34, /192.168.198.128:55142 => /192.168.198.128:44445] CONNECTED: /192.168.198.128:55142
21/01/25 18:16:42 INFO sink.LoggerSink: Event: { headers:{} body: 63 63 63 0D ccc. }
21/01/25 18:16:48 INFO sink.LoggerSink: Event: { headers:{} body: 64 64 64 0D ddd. }
21/01/25 18:47:19 INFO sink.LoggerSink: Event: { headers:{} body: 65 65 65 0D eee. }
重启agent3,44446端口再次被激活:
21/01/25 18:50:10 INFO ipc.NettyServer: [id: 0x58750737, /192.168.198.128:45596 => /192.168.198.128:44446] OPEN
21/01/25 18:50:10 INFO ipc.NettyServer: [id: 0x58750737, /192.168.198.128:45596 => /192.168.198.128:44446] BOUND: /192.168.198.128:44446
21/01/25 18:50:10 INFO ipc.NettyServer: [id: 0x58750737, /192.168.198.128:45596 => /192.168.198.128:44446] CONNECTED: /192.168.198.128:45596
21/01/25 18:50:13 INFO sink.LoggerSink: Event: { headers:{} body: 66 66 66 0D fff. }
二.双层的Flume架构
这篇博客写的特别详细:Flume日志收集分层架构应用实践.
双层Flume的好处:
- 解耦,hdfs或者kafka需要升级时,第二层flume可以进行缓冲,不会影响第一层。
- 安全,hdfs或者kafka直接暴露给第一层不安全(第一层很多flume来自其他部门,第二层在本地)。
- 利于业务的分组管理,将第一组的繁杂业务在第二层可以进行分组。
- 小文件的数量会大大减少。
- 外部某个类型的业务日志数据节点需要扩容,直接在L1层将数据流指向数据平台内部与之相对应的L2层Flume Agent节点组即可。
三.单source多channel多sink
第一层source发送一个消息,channel1和channel2都会传输,agent2和agent3都会收到相同的数据,所以这种架构可以将同一份数据,即可以导入hdfs进行离线计算,也可同时导入实时框架进行实时计算,实现多用途。