简介压缩包内是已编译好的 Kafka 集群管理工具版本为 1.3.3.22面向大数据运维和开发人员解决自行编译耗时长、依赖配置繁琐的问题适合在 Linux 服务器上快速部署使用。该工具提供 Web 管理界面可查看 Kafka 集群的 Broker 状态、Topic 详情、分区与消费者组信息还能执行创建主题、修改配置等常用操作是日常监控和运维排障的实用助手。压缩包大小约 75.91MB内含可执行程序、启动脚本及 application.conf 等核心配置文件解压后只需将 Zookeeper 地址修改为集群实际节点即可启动整体部署路径清晰。已有 962 人学习或下载对于希望快速搭好 Kafka 可视化监控环境的技术人员来说这份编译产物能有效节省时间并帮助理解 Kafka-Manager 的目录结构和配置方式。1. 一个离线部署包就能管住 Kafka 集群从 kafka-manager-1.3.3.22 说起Kafka 集群管起来麻烦kafka-manager-1.3.3.22.zip 这个老牌离线包是很多内网环境里最稳的选择之一。它本质是一个 Scala 写的 Web 控制台解压后由 bin 脚本和 conf 配置驱动启动监听 9000 端口通过 Zookeeper 发现 Broker不需要往生产节点装任何 Agent网络通就行。日常的 Topic 管理、分区重分配、消费组 Lag 监控都能在页面上完成省去一条条敲命令行。适合 Kafka 版本在 0.8 到 0.10 左右的集群也适合离线交付或没有外网依赖的现场。新手拿它当统一入口很直观老手拿它与命令行互补看一个集群的状态能少花一大半时间。2. 开局先盘底JDK 8、Zookeeper 地址与 Kafka 版本匹配的兼容问卷2.1 kafka-manager 的连管方式先记牢“它不碰 Broker”这句话很多第一次接触的人会下意识以为 kafka-manager 是像 Kafka 客户端一样直连 Broker 的。实际上它的运行路径是“kafka-manager → Zookeeper → 发现 Broker 列表与 Topic 元数据”也就是说只要 kafka-manager 所在机器能访问 Zookeeper 的 2181 端口它就能在界面上画出整个集群的拓扑。这也解释了为什么它启动时根本不关心 Kafka broker 地址。这个设计带来的一个实际好处是部署位置很自由。我一般会把 kafka-manager 放在一台独立的运维机上而不是塞进 Kafka 节点里。运维机只需要和 Zookeeper 端口互通浏览器只需要能访问 kafka-manager 的 9000 端口像我在某个现场就是把它装在监控网段内生产数据面照常跑排查问题的人不用去碰 Broker 机器。另一个隐含点是 Zookeeper 的安全性。因为 kafka-manager 对 Zookeeper 有读写权限它所在机器的网络隔离就要和客户端一样对待。如果 ZK 开了 ACL需要在配置里补齐认证信息否则 kafka-manager 只能看到部分节点或直接拒绝连接。这个位置容易被当成普通 Web 服务忽略但它实际掌握着集群元数据的写入口权限配错会直接影响分区管理的操作。2.2 下载包里有什么先数清三个关键路径下载下来的 zip 解压以后真正需要关心的路径其实只有三个conf/application.conf应用主配置Zookeeper 地址、端口、日志级别都写在这里。bin/kafka-manager启动脚本。脚本本质是一个 shell 包装设置 JAVA_HOME、JVM 参数后拉起 Java 进程。lib/整个应用依赖的 jar 包都被打在里面。由于是 Scala 和 Play 框架的老版本lib 目录体积不小但好处是内外依赖一次打包离线环境不用再折腾 Maven 仓库。还有一个常见误区这个包不内置 JDK也不内置 Zookeeper它只负责提供一个 Web 管理端。启动前先确认机器上有 JDK 8JDK 11 虽然能起来但会有兼容问题这点在避坑章节会展开。确认命令很简单java -version 21 | head -3 echo stat | nc localhost 2181第一条命令看 JDK 版本第二条命令看 Zookeeper 是否存活。echo stat是 Zookeeper 的四字命令之一如果返回包含Mode:的行说明客户端连接链路是通的如果 nc 都不存在先装 netcat 或者用bash -c cat /dev/null /dev/tcp/主机/2181代替。这个检查最好在部署前就做避免配置写完了才发现网络基线不通。还有一个容易踩的小地方解压之后第一件事不要急着改配置先跑一遍目录里的依赖自检。部分发布渠道的 zip 文件在传输过程中会丢文件常见表现是缺失某个 jar 导致启动时 ClassNotFound。可以先在 lib 目录下随便挑几个关键的 jar用jar tf看一下内容能否读取。这一步在离线环境里价值很高因为没网络就意味着没法临时去仓库拉包文件完整性就是启动的前提。2.3 版本选型对照为什么还选 1.3.3.22 而不是新分支Kafka Manager 这个项目后来改名为 CMAK新分支对 Kafka 0.11、1.0、2.x 的支持明显更好。那为什么还要用 1.3.3.22因为它是存放 Kafka 0.8 到 0.10 时代集群信息的“旧版通行证”。如果现场集群本来就是 0.10.x用新分支 CMAK 反而需要处理一部分接口兼容问题而 1.3.3.22 在这个版本段下最成熟。做一个简单的对照表场景1.3.3.22CMAK 新分支Kafka 0.8 / 0.9 / 0.10匹配良好能用部分路径变化Kafka 1.x / 2.x不适用推荐内网离线部署解压即用依赖完整规范但需要更多 JVM 选项消费组 Lag 查看读 ZK 路径老集群准确读取协调器 offset更适合新集群我并不是劝人守着老版本不放而是想说清楚边界如果你的 Kafka 已经升到 2.x直接用 CMAK如果还是 0.10 左右的老集群1.3.3.22 的开箱成本最低。选型时还有一个现实因素——很多现场拿不到公网依赖而老版本 zip 内部自带的 lib 目录确实省掉了下载环节这对离线交付是实质的便利。选型上我还习惯检查一个硬条件集群里有没有启用特殊的 SASL 机制。老版本 zip 对 SASL 配置文件的处理和新分支有差异如果团队里已经有成熟的 Kerberos 配置先拿测试集群验证一遍再定。Kafka Manager 本质是运维辅助工具选型的第一原则永远是“别给生产环境添负担”。3. 解压到跑通application.conf 核心配置与启动脚本拆解3.1 解压与目录结构确认拿到 zip 先解压到固定目录。我习惯放在 /data/apps 下面方便后续做日志转储和权限管理mkdir -p /data/apps cd /data/apps unzip kafka-manager-1.3.3.22.zip cd kafka-manager-1.3.3.22 ls -lhls -lh主要看三个点bin 目录是否有执行权限、conf 下 application.conf 是否存在、logs 目录是否被解压出来没有也没关系启动时会自动创建。解压后的目录名因为不同渠道可能带版本后缀建议统一改名成不带版本号的目录比如mv kafka-manager-1.3.3.22 kafka-manager这样后续写 systemd 服务、写巡检脚本都不容易把版本号写死。这一步最容易被忽略的是执行权限。如果 bin/kafka-manager 没有 x 权限直接执行会报 Permission denied先补一把chmod x bin/kafka-managerchmod 之后再用ls -l bin/kafka-manager确认第一列是-rwxr-xr-x或类似带 x 的组合再继续后面的配置修改。3.2 必改配置zkhosts、端口、消费者属性文件打开 conf/application.conf核心改动集中在 kafka-manager 配置块kafka-manager { zkhosts10.10.1.11:2181,10.10.1.12:2181,10.10.1.13:2181 port9000 consumerPropertiesFile/data/apps/kafka-manager/conf/consumer.properties }这三个参数的语义分别是zkhosts 是 Zookeeper 地址列表逗号分隔不需要加zookeeper://前缀也不要加尾部斜杠port 是 HTTP 监听端口改成 8080 或 9001 都可以但要注意启动脚本里如果有-Dhttp.port会覆盖这里的值consumerPropertiesFile 是自定义消费者属性文件路径当需要给 kafka-manager 自己的监控消费指定 group.id 时使用不配置也能跑起来只是部分消费组页面功能会用默认值。还有一个容易忽略但实际影响体验的参数是配置里与轮询刷新相关的周期项。界面上的 Topic 列表、消费组 Lag 默认隔一段时间轮询一次如果你发现“改了 Topic 后页面半天不更新”多半是这个轮询间隔太大。把间隔调小一点可以让页面展示更敏感不过也要注意别太频繁免得把 Zookeeper 的读取压力打高。更新频率折中在 5 到 10 秒之间比较常见。3.3 启动脚本里的 JVM 参数与后台运行方式启动前先确认当前用户对目录有写权限kafka-manager 会把运行日志写到 logs/application.log如果启动失败这里会给出第一手原因。启动命令不复杂export JAVA_HOME/usr/local/jdk1.8 export PATH$JAVA_HOME/bin:$PATH nohup bin/kafka-manager /dev/null 21 nohup把进程挂在后台 /dev/null 21丢弃启动时的控制台输出避免日志文件和 nohup.out 互相污染。这时最需要做的一件事是等待进程起来后立即访问首页或接口确认监听正常ss -lntp | grep 9000 tail -50 logs/application.logss的输出里如果能看到:9000并且进程名是 java 说明端口已起来tail日志则是为了确认没有抛出异常堆栈。有些环境启动后端口看似在监听但日志里已经开始循环报错所以端口和日志两个检查缺一不可。JVM 参数是很多老手会忽略的细节。默认脚本里给的堆内存偏小如果集群的 Topic 很多页面打开时会明显卡顿。我一般会在 bin/kafka-manager 脚本头部找到JAVA_OPTS一行把-Xmx512m改成-Xmx2g。改完以后重启进程再看一次能明显感受到列表刷新速度改善。踩这种“配置没生效”的坑多半是改错了位置改到了 application.conf 而没改脚本里的 JVM 参数。4. 把集群注册进界面Cluster、Topic 与消费组 Lag 的三个实操点4.1 页面注册集群五个必填项与一个版本下拉框进程跑起来以后浏览器打开http://运维机IP:9000。第一次进入会看到引导页点击 Add Cluster 开始注册第一个集群。界面上必填的内容包括 Cluster Name、Cluster Zookeeper Hosts、Kafka Version、JMX 开关和安全协议设置这里每一项都直接决定 kafka-manager 能不能正确识别集群。Cluster Name 是一个本地逻辑名称只用于界面上区分集群不要求与 Kafka 服务名一致但要保证唯一。Cluster Zookeeper Hosts 这一段与 application.conf 里的 zkhosts 格式一致同样用逗号分隔建议把同一套 ZooKeeper 下的所有节点都写进去Kafka Version 的下拉框要选和集群实际版本匹配的选项。这里有个经验版本号选得比实际高半档往往能正常工作但选得明显偏老会让部分新 Topic 元数据解析失败所以尽量选精确版本。JMX 开关影响两类信息一是 Broker 节点的运行状态指标二是部分线程池和网络统计。如果 Kafka 启动时开了 JMX 端口这里就勾选并填写 JMX 端口和认证没开就保持关闭避免 kafka-manager 反复尝试连接不存在的端口导致页面缓慢。安全协议设置一般场景下用默认但 Zookeeper 带 Kerberos 或 SASL 的环境必须在 Advanced Configuration 中补齐。第一次接入如果有些信息不确定可以先少填一两个非关键项保存再在集群列表里点进去补改保存后 kafka-manager 会重新拉取元数据。另外注意 ZK 地址尽量写全。只写一个节点时如果该节点正在选主页面会短暂出现连接抖动写全三节点后kafka-manager 的重连逻辑会自动切到可用节点这个细节在跨机房容灾场景下比想象中重要。4.2 用页面完成一次 Topic 创建、分区扩容与手动迁移进入已注册的集群视图左侧菜单的 Topic 标签是日常使用频率最高的入口。新建 Topic 时页面会要求填 Topic 名称、Partitions 分区数、Replication Factor 副本数还会显示一个有效 Broker 数量的提示。Partitions 直接决定了每条消息的并行度。如果消息量不大分区数建议设置成 Broker 数量的整数倍这样负载能尽量均匀落盘Replication Factor 则按可靠性标准至少填 2容忍单点故障则填 3。当一个 Topic 跨多个 Broker 时页面上用颜色块展示副本分布哪一台机器出了问题对应色块会变成异常状态。这个可视化是命令行不容易比上的地方也是我推荐别人用它的理由之一。创建之后还支持直接改分区数。kafka-manager 页面提供增加分区的操作输入新的总数然后确认它会把新分区分配进现有副本结构。需要提醒的是分区数只能增加不能减少这是 Kafka 底层的限制再怎么改也降不回去。所以创建时宁可规划大一点也不要指望后续缩水。除了分区数页面还提供 Generate Partition Assignments 功能用来手动迁移分区副本。选择 Topic 后可以按机器负载手工计算新分配方案也可以用默认方案一键生成。生成后的方案会给出每个 Broker 上的副本数量提交后 kafka-manager 会把重分配任务下发到集群。注意这个过程会持续一段时间的轮转期间页面会显示重新分配的状态进度。我建议在业务低峰期操作因为部分副本在迁移时会占用网络带宽对高吞吐场景有感知。4.3 消费 Lag 从哪看那个黑匣子怎么被打开的消费组 Lag 在 kafka-manager 里是开箱即用的核心功能。点击 Consumers 标签就能看到消费组列表每个消费组展开后能看到它消费的 Topic、分区号、LogSize 日志总量、Current Offset 当前位移以及 Lag 滞后量。Lag LogSize - Current Offset这个差值理论上应该是一个稳定的小数字如果某个分区 Lag 持续增长说明消费者处理速度跟不上写入速度。老版本 kafka-manager 对消费组状态的读取路径和 Kafka 自身的位移存储机制有直接关系。对 0.8、0.9 时代的消费者位移默认存在 Zookeeper 里kafka-manager 通过 ZK 路径读取是准确的对 0.10 之后使用新消费者 API 的组位移落到了 Broker 内部的 __consumer_offsets 主题里这时老版本界面上的 Lag 只能反映一部分情况严重时会出现“消费者明明在干活Lag 却纹丝不动”的假象。理解这一层后续排错才能不慌。补一个判断技巧打开 Consumers 列表后如果看到某个 Group 的 Owner 列是空说明这个消费组当前没有活动消费者成员Lag 自然不会被更新。这时候不要只盯着 Lag 数字先确认消费者进程是否还活着。页面 Owner 列、Topic 分区数和消费者实例数三者应该能相互印证这是排查消费停滞最快的一组信号。5. 避坑记录部署后最容易翻车的五个问题5.1 集群状态一直红色先查 Zookeeper 地址有没有写对 chroot现象集群注册后状态图标长期显示红色点击 Test Connection 也提示失败或者刷新后只有部分 Broker 出现。原因最常见的是 Zookeeper 地址后面带了 chroot 路径但路径前缀和 Kafka 实际使用的路径不一致。很多 Kafka 集群会在 Zookeeper 下建 chroot 目录比如/kafka-prod页面填地址时写成zk1:2181/kafka-prod如果实际 Kafka 配置的 chroot 是另一个路径kafka-manager 能连上 ZK 但查不到 broker 节点。解决先用 Zookeeper 命令行工具echo get /brokers/ids | nc zk1 2181对比一下实际路径再把页面和 application.conf 里的地址改成同一个。我处理过几次这类问题最后都发现不是网络不通而是路径差一级。5.2 本机能开页面、远程打不开监听地址与防火墙各查一遍现象在运维机上curl http://127.0.0.1:9000正常但换一台电脑访问http://运维机IP:9000超时。原因两种情况最多一是启动脚本里被人为加上了-Dplay.http.address127.0.0.1这类参数把监听地址限制在了回环地址二是系统防火墙没有放行 9000 端口。解决先用ss -lntp | grep 9000看监听地址是 0.0.0.0 还是 127.0.0.1如果绑在回环检查启动脚本和环境变量里的 http.address 配置如果监听是 0.0.0.0 但外部仍不通再检查 firewalld 或 iptables。这一步的顺序别反先看监听再动防火墙否则排查了半天改了个寂寞。5.3 点进某个 Topic 就报错副本分布异常时先回命令行处理现象Topic 列表能正常显示但点击特定 Topic 后页面报错有时伴随 No leader 或分区状态异常。原因这类 Topic 通常存在副本分配不合理的情况比如某个分区的 leader 副本在宕机节点上或者副本因子超过了存活 Broker 数量kafka-manager 在渲染页面时要拉取每个分区的 ISR 集合拉不动自然报错。解决回到 Kafka 命令行修复底层数据用kafka-leader-election.sh先对异常分区做一次优先副本选举用kafka-topics.sh --describe确认 ISR 恢复后再回到界面刷新。kafka-manager 本身不做数据修复这一点不要指望它。5.4 JDK 版本太高导致 Actor 初始化失败现象启动后没有正常监听端口或者进程起来了但 logs/application.log 里连续出现 akka Actor 初始化相关的异常堆栈。原因1.3.x 系列基于老版本 Scala 和 Play 框架对 JDK 9 以上模块化系统的兼容性不足频繁出现非法反射访问。解决把 JAVA_HOME 指到 JDK 8 后重启进程这一步基本能消除异常。我的建议是部署脚本里显式export JAVA_HOME/usr/local/jdk1.8不要依赖系统的默认 Java。这个坑属于典型的“本地能跑线上就挂”根源往往是启动环境变量没锁死。5.5 Lag 显示异常老版本消费组读的是 ZK 位移现象某个消费组在持续消费但页面上 Lag 数值停留在某个固定值或异常增长。原因上面 4.3 已经提到老版本 kafka-manager 对消费组位移的读取依赖 Zookeeper 路径而新消费者 API 的位移存储在 Broker 内部主题数据源不一致导致展示失真。解决先用kafka-consumer-groups.sh --describe对比命令行输出确认真实 Lag如果集群已经是 0.11 以上就别用 1.3.x 看消费组升级到 CMAK 新分支或直接以命令行结果为准。这不是 kafka-manager 坏了而是它的数据源本来就是旧时代的产物认清边界比反复重启有效。6. 进阶用 REST API 做巡检顺便评估升级迁移的路kafka-manager 虽然是个 Web 页面但它内置了一套 REST 接口最常用的就是集群列表接口。在浏览器开发者工具里点开任意一次页面刷新都能看到请求走的路径右键复制为 cURL 就能把同样的请求搬到命令行。我日常巡检的脚本就是这么拼出来的curl -s http://127.0.0.1:9000/api/clusters | python3 -m json.tool这个命令返回集群列表的 JSON 结构用 python3 -m json.tool 能把没有缩进的响应格式化输出比直接看一行长报告清晰得多。如果机器上没有 python3用jq .效果一样。拿到集群标识后再配合页面刷新时观察到的具体接口路径就可以把它变成一条巡检命令。我的做法是写一个 cron 每分钟请求一次当返回内容里出现 Error 关键字时把告警发到内部群里比每天肉眼盯页面靠谱。*/1 * * * * cd /data/apps/kafka-manager curl -s http://127.0.0.1:9000/api/clusters | grep -i error /tmp/km_alert这个 cron 的写法比较粗糙grep -i error会误报也可能漏报但作为最先感知异常的哨兵已经够用。真要做阈值告警还是该用 consumer-groups 命令去对数。我把它放在这里是为了说明一个思路kafka-manager 的价值不止于点鼠标它的接口完全能融入现成的告警链路。如果考虑把集群迁到更新的 Kafka 版本迁之前先用这条 API 把当前集群的 Topic、分区配置、消费组列表导一份存档。升级完成后再用 CMAK 新分支打开同样路径做差异对比哪里丢了配置一目了然。这也算给旧包留了一条“后悔药”路径。从那以后我每次帮人装 kafka-manager 都会先问一句你的 Kafka 是哪个版本、ZK 走没走 chroot、位移存在哪里。想清楚这三个问题旧工具也能用得明明白白。希望帮到你。本文还有配套的精品资源点击获取