暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / Kafka跨网络使用问题排查

Kafka跨网络使用问题排查

IT那活儿 2022-10-02
1087
点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

近期在实现某个功能点上线生产环境，发现访问受限，导致采集的数据无法入到kafka，碰到此类问题，我们把分析过程记录一下。

一

功能流程

  • 分部：通过调度平台定期采集指标数据，执行器采集数据后，将数据外吐给总部slb。

  • 总部：利用 slb 配置代理转发到kafka ，然后由数据处理模块对kafka 数据做相关逻辑处理。

二

问题描述

当采集执行器采集到指标数据发送给slb ，再由slb 将数据转发到kafka ，后台提示如下报错信息：
Connection to node 0 (/21.xx.xx.7:xx) could not be established. Broker may not be available.

从错误信息提示kafka地址与端口无法调通，broker 不可用。

三

问题分析

针对此类问题，采用分段分析方式对问题进行排查分析：

1）网络检查从省端ping 及telnet 到集团端服务情况如下

  • 省端到集团端slb网络正常。

  • 省端和集团分属不同的网络，省侧到集团端kafka网络受限，kafka是集团内部服务，不直接开放给省侧访问。

2）省侧采集程序排查
在省侧部署跟集团侧相同版本kafka 环境，利用Kafka 客户端命令连接集团slb进行生产消息，提示超时报错信息，通过这种验证方式，可以排出不是省侧调度程序的问题。
org.apache.kafka.common.errors.TimeoutException: Topic not present in metadata
3）集团侧链路排查
  • 验证集团侧slb到kafka 网络是相通的。
  • 集团侧部署一个新的kafka 服务，利用Kafka 客户端命令远程连接集团slb/kafka进行生产消息，kafka topic 能正常收到信息。
通过以上两个排出集团侧内部链路问题。
四

问题解决

从上面几点分析，可以排查出省侧与集团侧自身的链路问题，省侧程序是直接跟slb 进行通讯，但又提示连接Kafka超时报错信息，检查slb 到kafka 本身链路也没有问题，说明问题出在跨网络使用kafka 造成的原因。
第一次交互流程（1/2/3/4）客户端获取到的真实的kafka的ip信息，而第二次交互的时候client会根据kafka 的ip 信息直接去访问kafka 地址，因为跨网络受限，所以第二次交互出现连接超时报错现象。
针对跨网络使用kafka情况下，需要在kafka 开启advertised.listeners参数配置。根据此参数描述，它是用于暴露给外部的listeners，如果没有设置，会读取listeners参数内容，而listeners参数记录的是本机kafka 监听端口。
# Hostname and port the broker will advertise to producers and consumers. If not set,
# it uses the value for "listeners" if configured. Otherwise, it will use the value
# returned from java.net.InetAddress.getCanonicalHostName().
#advertised.listeners=PLAINTEXT://your.host.name:9092
当省侧客户端发送数据第一次跟slb建立连接后 ，kafka 会返回advertised.listenersr所配置的内容给客户端，后面省侧客户端会根据advertised.listenersr的值解析出对应的域名或者ip。根据这些信息，客户端再次访问到slb，由slb  转发到真实Kafka服务，才能实现链路流转正常。
advertised.listeners=PLAINTEXT://slb ip 地址:9092
因为跨网络受限，对外提供服务listeners 配置成slb ip或者域名及对应的端口，不能配置成kafka 自身的ip 与端口，才能在跨网络下通过代理转发方式给后端kafka 推送数据。



本文作者：长研架构小组（上海新炬王翦团队）

本文来源：“IT那活儿”公众号

kafka
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论