flume跨机房拉取内网kafka消息的问题

原来flume跨机房拉取(公网IP)的kafka服务器消息一切正常，业务迁移到openstack虚拟机后遇到了坑。

注: openstack没有公网IP

flume拉取日志错误

由日志报错可确定flume、kafka和zookeeper的工作流程。

首先,机房2的flume跨机房找机房1的zookeeper(flume里面配置了另一个机房的zookeeper集群信息；能跨机房连接这一步肯定是配置了NAT的), zookeeper告诉flume：我给你我这边的kafka的地址，你自己去联系并索要(由lua二次开发的nginx产生的)kafka消息，于是zookeeper就把kafka内网IP给了flume，flume拿到内网kafka的IP地址和端口就懵逼了,我TM连接不上啊......

这就是你看到的flume日志的报错,一直在重试连接并不断返回连接失败。

方案解决-思路

前提:
1.机房1和机房2的kafka需要有相同的topic,没有就创建。
2.机房1的zookeeper集群需要完成DNAT映射,让机房2的flume能连接过去

刚才已经分析完了报错信息，下面就尝试去解决。

KAFKA配置-修改监听域名(非内网IP)-是否能解决问题？

带着疑问，各种修改，hosts添加解析，各种NAT映射，最后测试结果是：

(1)在机房1的kafka生产消息，在机房2的kafka消费消息，测试OK，这样的话跨公网的问题就解决了。需要注意的是，需要在机房2的flume服务器配置hosts把域名指向机房1的DNAT映射。

(2)在测试机房1的业务POST请求是否能被机房2的flume拉取的过程中, 机房2的flume竟然无法消费，什么尼玛情况...刚才已经确认机房1和机房2的kafka直接没有问题，那么问题就可能出现在(机房1的)lua-Nginx到(机房1)kafka的过程出现了错误。

经过查看lua二次开发的Nginx错误日志可以发现这一条信息：
producer.lua:255: buffered messages send to kafka err: test76.xxx.com could not be resolved (110: Operation timed out), retryable: true, topic: test, partition_id: 4, length: 1, context: ngx.timer, client: X.X.X.X, server: 0.0.0.0:80

这条信息很明显,说kafka由监听内网IP改为监听域名后,这个域名无法解析，Lua-Nginx生产消息后发送到同机房的kafka过程中发生了错误。

各种Google、某度，尝试了大半天，配置改的乱七八糟，最后得出一个结论：用Lua二次开发的Nginx "他妈的"不支持向kafka域名监听的地址发送生产的业务消息。无奈整套方案放弃,修改的配置全部恢复。

最后通过官方文档了解到KAFKA如下两个参数

advertised.host.name=X.X.X.X
advertised.port=9092

这两个kafka配置参数意思是：把这个地址注册到zookeeper，当外部(机房2)flume等程序过来请求zookeeper的时候,zookeeper告诉外部程序flume, kafka的IP地址和端口是这两个参数定义的，(这个IP可以是公网IP)，这就好办了，当配置了公网IP,flume就能找到机房1的kafka集群了。

实施: 在机房1的kafka集群的机器中，每台kafka集群配置中都加这两个参数，保存，重启kafka,重启zookeeper。
注:这个参数的公网IP和端口需要提前在iptables完成DNAT映射。

---------------------------------------------------------------------------------------------
最终测试：
1. 在机房1 POST访问请求Lua-KAFKA,让其产生消息
2. 在机房1的kafka查看Topic为test的消费消息(速度最快)
3. 在机房2的kafka查看Topic为test的消费消息(由于跨公网,速度稍有延迟)
4. 把测试的Topic改为正式的Topic即可。

测试结果:完美+感人！

参考:

KAFKA官方说明文档

KAFKA常用命令参考

• 本文作者： GaryWu
• 本文链接： https://garywu520.github.io/2017/08/07/flume跨机房拉取内网kafka消息的问题/
• 版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！