后端消息队列运维可观测性【免费下载链接】KnowStreaming一站式云原生实时流数据平台通过0侵入、插件化构建企业级Kafka服务极大降低操作、存储和管理实时流数据门槛项目地址https://gitcode.com/gh_mirrors/kn/KnowStreaming点击查看免费下载Kafka 通过 JMXJava Management Extensions暴露运行指标KnowStreaming 作为实时流数据平台需要主动连接 Broker 的 JMX 服务来完成指标采集。本指南基于开源仓库中的官方排查文档系统梳理「JMX 未开启、JMX 配置错误、JMX 开启 SSL、连接了错误 IP、连接了错误端口」五类典型异常现象与对应修复方案并结合仓库源码讲解 KnowStreaming 底层 JMX 连接机制帮助读者快速定位并解决页面指标缺失问题。1、背景KnowStreaming 为什么依赖 JMXKafka Broker 的运行时指标如消息吞吐、分区负载、请求时延等通过 JMX 服务暴露因此KnowStreaming会主动连接 Kafka 的 JMX 服务进行指标采集。如果我们发现页面缺少指标那么可能原因之一是 Kafka 的 JMX 端口配置的有问题导致指标获取失败进而页面没有数据。从源码结构看KnowStreaming 的 JMX 连接能力由多个模块协同完成连接封装层km-common 的 JmxConnectorWrap 负责真正建立service:jmx:rmi:///jndi/rmi://{host}:{port}/jmxrmi连接并支持用户名/Token 认证与 SSL 加密客户端管理层KafkaJMXClient 以clusterPhyId brokerId为维度缓存JmxConnectorWrap实例并在集群信息含jmxProperties变化时自动重建连接端口决策层JmxConfig 负责根据元信息、页面配置与自定义配置最终确定连接哪一个 JMX 端口与 IP。KnowStreaming 还定义了 JmxEnum-1表示「未开启 JMX 端口」-2表示「JMX 端口未知」这两个哨兵值在后续排查中会反复出现。2、异常与正常现象判定2.1、异常现象Broker 列表的JMX PORT列出现红色感叹号则表示 JMX 连接存在异常。2.2、正常现象Broker 列表的JMX PORT列出现绿色则表示 JMX 连接正常。判定逻辑对应到源码JmxConnectorWrap.checkJmxConnectionAndInitIfNeed()会先检查jmxPort若端口为null或-1即 JmxEnum.NOT_OPEN则直接判定不可用并返回false否则尝试创建连接器。连接成功即视为正常失败则记录methodcreateJmxConnector||...||msgjmx connect exception.类错误日志并返回false。创建连接失败的异常日志由JmxConnectorWrap统一输出形如2021-01-27 10:06:20.730 ERROR 50901 --- [ics-Thread-1-62] c.x.k.m.c.utils.jmx.JmxConnectorWrap : JMX connect exception, host:192.168.0.1 port:9999. java.rmi.ConnectException: Connection refused to host: 192.168.0.1; nested exception is:3、异因一JMX 未开启3.1、异常现象Broker 列表的JMX Port值为-1对应 Broker 的 JMX 未开启。这正是JmxEnum.NOT_OPEN(-1)的语义当 Kafka 元信息中jmx_port为-1时KnowStreaming 判定该 Broker 未开启 JMX不会发起连接。3.2、解决方案开启 JMX开启流程如下步骤 1修改 Kafka 的 bin 目录下的kafka-server-start.sh文件# 在这个下面增加JMX端口的配置 if [ x$KAFKA_HEAP_OPTS x ]; then export KAFKA_HEAP_OPTS-Xmx1G -Xms1G export JMX_PORT9999 # 增加这个配置, 这里的数值并不一定是要9999 fiJMX_PORT的值可按实际规划填写例如 8099、9999 等关键是保持与 KnowStreaming 页面接入集群时填写的 JMX 端口一致。步骤 2修改 Kafka 的 bin 目录下的kafka-run-class.sh文件# JMX settings if [ -z $KAFKA_JMX_OPTS ]; then KAFKA_JMX_OPTS-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticatefalse -Dcom.sun.management.jmxremote.sslfalse -Djava.rmi.server.hostname当前机器的IP fi # JMX port to use if [ $JMX_PORT ]; then KAFKA_JMX_OPTS$KAFKA_JMX_OPTS -Dcom.sun.management.jmxremote.port$JMX_PORT -Dcom.sun.management.jmxremote.rmi.port$JMX_PORT fi注意-Djava.rmi.server.hostname当前机器的IP必须替换为 KnowStreaming 实际能够访问到的机器 IP。若配置成127.0.0.1或错误的内网/外网 IP则属于下文「异因二/异因四」的场景。步骤 3重启 Kafka-Broker使上述配置生效。重启后回到 KnowStreaming Broker 列表若 JMX PORT 列由-1变为绿色则说明开启成功。4、异因二JMX 配置错误4.1、异常现象错误日志通常呈现两种形态可用于区分问题归属# 错误一错误提示的是真实的IP这样的话基本就是JMX配置的有问题了。 2021-01-27 10:06:20.730 ERROR 50901 --- [ics-Thread-1-62] c.x.k.m.c.utils.jmx.JmxConnectorWrap : JMX connect exception, host:192.168.0.1 port:9999. java.rmi.ConnectException: Connection refused to host: 192.168.0.1; nested exception is: # 错误二错误提示的是127.0.0.1这个IP这个是机器的hostname配置的可能有问题。 2021-01-27 10:06:20.730 ERROR 50901 --- [ics-Thread-1-62] c.x.k.m.c.utils.jmx.JmxConnectorWrap : JMX connect exception, host:127.0.0.1 port:9999. java.rmi.ConnectException: Connection refused to host: 127.0.0.1;; nested exception is:日志中报出真实 IP且连接被拒Connection refused说明 JMX 本身配置存在问题例如-Djava.rmi.server.hostname未设置、端口未真正监听或防火墙拦截了该端口日志中报出127.0.0.1则说明机器的 hostname 配置可能有问题——Kafka 启动时解析出的主机名指向了本机回环地址导致 KnowStreaming 拿到127.0.0.1后无法跨机器访问。4.2、解决方案开启 JMX 并修正配置流程如下步骤 1修改 Kafka 的 bin 目录下的kafka-server-start.sh文件# 在这个下面增加JMX端口的配置 if [ x$KAFKA_HEAP_OPTS x ]; then export KAFKA_HEAP_OPTS-Xmx1G -Xms1G export JMX_PORT9999 # 增加这个配置, 这里的数值并不一定是要9999 fi步骤 2修改 Kafka 的 bin 目录下的kafka-run-class.sh文件# JMX settings if [ -z $KAFKA_JMX_OPTS ]; then KAFKA_JMX_OPTS-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticatefalse -Dcom.sun.management.jmxremote.sslfalse -Djava.rmi.server.hostname当前机器的IP fi # JMX port to use if [ $JMX_PORT ]; then KAFKA_JMX_OPTS$KAFKA_JMX_OPTS -Dcom.sun.management.jmxremote.port$JMX_PORT -Dcom.sun.management.jmxremote.rmi.port$JMX_PORT fi关键点在于-Djava.rmi.server.hostname必须设置为当前机器的真实 IPKnowStreaming 可访问的地址且jmxremote.port与jmxremote.rmi.port保持一致均取自JMX_PORT避免 RMI 端口与注册端口不一致导致连接被拒。步骤 3重启 Kafka-Broker使配置生效后重新观察 KnowStreaming 的 Broker 列表状态与日志。5、异因三JMX 开启 SSL5.1、异常现象在连接 JMX 的日志中出现 SSL 认证失败的相关日志例如握手失败、证书校验失败等 SSL 相关异常原文档中该场景的具体日志案例以 TODO 标记待补充读者可在实际运行中收集methodcreateJmxConnector||...||msgjmx connect exception.附近的堆栈进行比对。5.2、解决方案在 Broker 端关闭 JMX 的 SSL 配置即将kafka-run-class.sh中的-Dcom.sun.management.jmxremote.sslfalse保持为false或显式设置为 false随后重启 Kafka-Broker。从 KnowStreaming 侧看若 Broker 端确实开启了 SSL也可以在集群的jmx_properties中配置openSSL为true并配套username、password使 KnowStreaming 使用SslRMIClientSocketFactory建立加密连接。对应源码位于 JmxConnectorWrap.createJmxConnector当openSSL为 true 时会向连接环境注入Context.SECURITY_PROTOCOLssl与SslRMIClientSocketFactory。注意当openSSLtrue时KnowStreaming 要求username与token即 password均非空否则无法完成带认证的 SSL 握手具体约束见 JmxAuthConfig。6、异因四连接了错误 IP6.1、异常现象Broker 配置了内外网而 JMX 在配置时可能配置了内网 IP 或者外网 IP此时KnowStreaming需要连接到特定网络的 IP 才可以进行访问。比如Broker 在 ZK 的存储结构如下所示我们期望连接到endpoints中标记为INTERNAL的地址但是KnowStreaming却连接了EXTERNAL的地址{ listener_security_protocol_map: { EXTERNAL: SASL_PLAINTEXT, INTERNAL: SASL_PLAINTEXT }, endpoints: [ EXTERNAL://192.168.0.1:7092, INTERNAL://192.168.0.2:7093 ], jmx_port: 8099, host: 192.168.0.1, timestamp: 1627289710439, port: -1, version: 4 }此时host字段指向的是192.168.0.1EXTERNAL 地址而 KnowStreaming 部署在 INTERNAL 网络内无法直连外部地址导致 JMX 连接失败、指标缺失。6.2、解决方案可以手动往ks_km_physical_cluster表的jmx_properties字段增加一个useWhichEndpoint字段从而控制KnowStreaming连接到特定的 JMX IP 及 PORT。jmx_properties格式{ maxConn: 100, // KM对单台Broker的最大JMX连接数 username: xxxxx, //用户名可以不填写 password: xxxx, // 密码可以不填写 openSSL: true, //开启SSL, true表示开启ssl, false表示关闭 useWhichEndpoint: EXTERNAL //指定要连接的网络名称填写EXTERNAL就是连接endpoints里面的EXTERNAL地址 }SQL 例子UPDATE ks_km_physical_cluster SET jmx_properties{ maxConn: 10, username: xxxxx, password: xxxx, openSSL: false , useWhichEndpoint: xxx} where id{xxx};useWhichEndpoint的值应填写endpoints中某个具体的 listener 名称如EXTERNAL或INTERNAL。从源码看Broker.getJmxHost(String endPoint) 会根据该值从 Broker 的endpointMap中取出对应的IpPortData作为 JMX 连接 IP若未配置或找不到对应端点则回退使用元信息中的host字段。而 JmxConfig.getFinallyJmxPort 再结合端口配置决定最终端口二者共同决定「连接哪个 IP 的哪个端口」。7、异因五连接了错误端口该能力仅 3.3.0 以上版本或 master 分支最新代码才具备。7.1、异常现象在 AWS 或者是容器上的 Kafka-Broker使用同一个 IP但是外部服务想要去连接 JMX 端口时需要进行端口映射。因此 KnowStreaming 如果直接连接 ZK 上获取到的 JMX 端口会连接失败因此需要具备连接端口可配置的能力。该场景的具体日志在官方文档中以 TODO 标记待补充。典型的场景是容器内 Broker 监听的 JMX 端口为1234但宿主机通过 NAT 映射暴露为2234KnowStreaming 从 ZK 元信息拿到的是容器内端口1234直连必然失败必须通过配置将端口纠正为映射后的2234。7.2、解决方案可以手动往ks_km_physical_cluster表的jmx_properties字段增加一个specifiedJmxPortList字段从而控制KnowStreaming连接到特定的 JMX PORT。jmx_properties格式{ jmxPort: 2445, // 最低优先级使用的jmx端口 maxConn: 100, // KM对单台Broker的最大JMX连接数 username: xxxxx, //用户名可以不填写 password: xxxx, // 密码可以不填写 openSSL: true, //开启SSL, true表示开启ssl, false表示关闭 useWhichEndpoint: EXTERNAL, //指定要连接的网络名称填写EXTERNAL就是连接endpoints里面的EXTERNAL地址 specifiedJmxPortList: [ // 配置最高优先使用的jmx端口 { serverId: 1, // kafka-broker的brokerId, 注意这个是字符串类型字符串类型的原因是要兼容connect的jmx端口的连接 jmxPort: 1234 // 该 broker 所连接的jmx端口 }, { serverId: 2, jmxPort: 1234 }, ] }SQL 例子UPDATE ks_km_physical_cluster SET jmx_properties{ maxConn: 10, username: xxxxx, password: xxxx, openSSL: false , specifiedJmxPortList: [{serverId: 1, jmxPort: 1234}] } where id{xxx};关于端口优先级源码 JmxConfig.getFinallyJmxPort 给出了明确决策顺序可按「最高 → 最低」理解specifiedJmxPortList最高优先级若当前serverId在列表中命中了具体jmxPort则直接使用该端口ZK 元信息中的jmx_port未命中特殊指定时若元信息端口不是-1未开启或-2未知则使用元信息端口jmxPort字段最低优先级元信息端口为空/未知时回退使用jmx_properties中配置的jmxPort若以上均不可得最终返回-1未开启。serverId特意设计为字符串类型原因是要兼容 Kafka Connect 的 JMX 端口连接场景——连接类组件同样通过该机制指定端口见 JmxConfig 中ListServerIdJmxPort specifiedJmxPortList的定义。8、总结与排查建议当 KnowStreaming 页面指标缺失时可按下述顺序快速排查序号排查项观察点处置1JMX 是否开启Broker 列表 JMX PORT 为-1按异因一开启 JMX2JMX 配置是否正确日志中 Connection refused 且指向真实 IP 或 127.0.0.1按异因二修正kafka-run-class.sh并重启3是否开启 SSL日志出现 SSL 认证失败按异因三关闭 SSL 或配置openSSL/username/password4是否连接了错误 IP内外网并存时连接了不可达地址按异因四配置useWhichEndpoint5是否连接了错误端口AWS/容器场景下端口映射导致直连失败3.3.0按异因五配置specifiedJmxPortList修改jmx_properties后KafkaJMXClient.modify()会检测jmxProperties是否变化一旦发现集群 JMX 配置变更即会移除旧连接并重建见 KafkaJMXClient因此配置生效无需重启 KnowStreaming 服务只需等待其重新建立 JMX 连接即可。最后建议所有 JMX 相关改动均应在 Kafka Broker 侧与 KnowStreaming 集群接入配置ks_km_physical_cluster.jmx_properties两侧核对一致并结合JmxConnectorWrap输出的methodcreateJmxConnector||...||msgjmx connect exception.日志定位真实失败原因避免盲目修改配置。赞分享后端消息队列运维可观测性【免费下载链接】KnowStreaming一站式云原生实时流数据平台通过0侵入、插件化构建企业级Kafka服务极大降低操作、存储和管理实时流数据门槛项目地址https://gitcode.com/gh_mirrors/kn/KnowStreaming点击查看免费下载相关推荐JMeter-Rabbit-AMQP插件完整实践教程JMeter Rabbit AMQP插件完整实践教程 项目定位与核心价值 JMeter Rabbit AMQP是一款专为Apache JMeter设计的消息队列SimpleWebRTC故障排除ICE连接失败的常见原因及修复方法SimpleWebRTC故障排除ICE连接失败的常见原因及修复方法 WebRTC实时通信技术让音视频通话变得简单便捷但在实际应用中ICE连接失败是开发者最音视频即时通讯终极解决方案Blueman游戏手柄连接失败深度排查与修复指南终极解决方案Blueman游戏手柄连接失败深度排查与修复指南 问题现象与痛点分析 你是否遇到过这样的情况新买的蓝牙游戏手柄Gamepad在Linux系统桌面应用通信上一篇开源项目管理终极指南OpenProject社区版完整免费使用教程下一篇3步掌握Python期权量化分析的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考