全部博文（163）
分类： 系统运维
2018-10-20 19:17:24
1. 背景
有8台linux服务器托管在外面，现在需要使用filebeat将其上的应用日志传回到本地ELK应用中的kafka集群进行收集。 8台服务器和kafka集群之间网络不直连，通过NAT进行了地址映射，kafka集群由188网段地址映射为172网段地址，从而跟8台linux设备可以正常通信。
|
8台linux服务器地址 |
kafka进行NAT后的地址 |
kafka服务器地址 |
|
172.23.xx.xx |
172.27.xx.xx |
188.4.xx.xx |
防火墙策略已经开通，从linux上可以ping通kafka映射后的地址（172.27.xx.xx），且也可以telnet通映射地址的9092端口（端口为kafka服务端口），且网络部门也调整了最大1450包大小的限制。
2. 现象
在linux服务器上安装部署了filebeat，且filebeat的配置文件中指定kafka集群的地址，形式为：host: ["172.27xx.xx:9092",
"172.27xx.xx:9092", "172.27xx.xx:9092"], 但是从kafka集群中发现可以创建相应成功相应的topic，但是无法收集任何日志。
3. 分析
通过在linux服务器上进行抓包分析（抓包命令 tcpdump -vv -t -s0 port 9092 -w 1.cap）分析，理论上是linux服务器172.23.xx.xx 跟映射后的地址 172.27.xx.xx之间的通信，但是却发现了报文中还夹杂着188.4.xx.xx， 如下图：
这肯定是有问题，进一步分析，看下图：
最上面的红框为linux服务器到kafka的三次握手。 中间的红框为kafka的响应报文，报文中明确的返回了broker的地址188.4.xx.xx。
Kafka协议client端会去请求broker地址，然后自主选择向那个brocker及partition中写入数据，所以client端应该会使用kafka协议中返回的brocker地址，从而导致进一步通讯中linux服务器会向188地址发送通讯，下图得以验证：
因为这些地址被kafka协议所使用，从而NAT设备无法更改，NAT设备只能更改报文头中的地址，而无法更改报文内容中的地址。
4. 测试
要让kafka返回的响应报文中不再直接包含188的IP地址，所以我们对一台kafka配置进行调整，server.properties中原本：
advertised.listeners=PLAINTEXT://IP:9092
listeners=PLAINTEXT://IP:9092
host.name=IP
advertised.host.name=IP
改为：
advertised.listeners=PLAINTEXT://elk1:9092
listeners=PLAINTEXT://elk1:9092
host.name=elk1
advertised.host.name=elk1
然后再在linux服务器中配置hostname 到映射地址的条目，/etc/hosts
elk1 172.23.xx.xx
且将filebeat.yml 文件中host: ["172.27xx.xx:9092", "172.27xx.xx:9092",
"172.27xx.xx:9092"]，改为：
host: ["elk1:9092"]
再次启动抓包，启动filebeat，报文中可以看出并没有再跟188的通讯：
也可以看出调整kafka配置已经生效，返回报文中broker一台已经变成了主机名elk1：
通过追踪tcp流，发现内容中还是存在其他kafka 188 的地址，
5. 处理
接下来我们将kafka集群中的配置都由IP调整为主机名，且在linux服务器上/etc/hosts/中添加了kafka映射后地址的条目，并将filebeat.yml都改为：
host: ["elk1:9092",
"elk2:9092", "elk3:9092"]
再启动filebeat，发现日志已经可以正常传送到kafka集群。
