简介面向需要搭建Kafka集群监控界面的运维人员与大数据开发工程师此资源为Kafka-Manager 1.3.3.22的已编译版本。压缩包为zip格式约75.91MB内含可直接解压运行的完整程序与配置文件免去Linux下源码编译和依赖处理环节。结合包内配置说明用户可快速部署至/opt/module目录修改application.conf中的Zookeeper地址以对接多节点集群并可通过自定义HTTP端口启动在浏览器中打开可视化管理界面集中监控Kafka主题、分区与消费组状态。目前已有962人学习下载适合具备基础Kafka知识、希望在真实分布式环境中快速落地监控工具的技术人员可大幅缩短部署与调试时间。1. 为什么过了这么多年我还在推荐 kafka-manager先说个真实现状Kafka 部署简单但日常管理真不算省心。Topic 多了以后谁记得每个分区副本落在哪个 broker 上消费者组卡住了用命令行一条条查 offset 能查到怀疑人生。就在这种能用但难受的状态下kafka-manager 几乎是 Kafka 生态里最老牌、最被低估的一个 Web 管理工具它依托 ZooKeeper 存储自身元数据能在浏览器里完成集群信息查看、Topic 增删改查、分区重分配、消费者 offset 监控这些高频操作。我用的这个版本是 kafka-manager-1.3.3.22本质上它保留了雅虎开源 kafka-manager 的核心架构又补了不少向后兼容的补丁。很多文章会建议你直接上新版 CMAK但实际在企业存量环境里1.3.3.22 反而是问题最少、最不需要反复折腾的一个选择。它不挑 JDK 到离谱的程度对 Kafka 1.x、2.x 的兼容性也都验证过尤其适合那种Kafka 版本不敢随便动、只想加个管理界面的场景。这篇文章不是给你背一遍 README而是把我从下载、部署到日常排障的过程完整摊开。你能看到这个工具能做什么、哪些地方容易踩坑、为什么某些配置必须那样写以及最后一版 kafka-manager 在实际运维里的真正价值边界。2. 版本号里的门道为什么是 1.3.3.22 而不是最新的 CMAK2.1 kafka-manager、CMAK、1.3.3.22 三者到底是什么关系很多人第一次接触这个项目时会被名字搞晕。kafka-manager 是 Yahoo 在 2015 年前后开源的管理工具项目代号 KMN代码仓库后来归档。社区接手后 fork 出一个叫 CMAKCluster Manager for Apache Kafka的新项目版本号从头续到 3.x。所以你在 GitHub 上搜 kafka-manager 会看到大量已停止维护的提示但搜 CMAK 则是活跃的。那 1.3.3.22 算老古董吗单纯从版本号看确实旧但它属于第三方编译定制版是一个带补丁的 1.3.3.x 维护线。它修复了原版某些场景下消费组刷新过慢、迁移任务状态不一致的问题同时保留了原版那种清爽到近乎简陋的 Web 界面。很多公司生产环境至今跑着 Kafka 2.3、2.6切到 CMAK 3.x 反而需要额外适配而 kafka-manager 1.3.3.22 直接拉起来就能连旧集群。2.2 这个版本适合谁、不适合谁先说不适合的如果你的 Kafka 已经上了 2.8 以上或者重度使用 KRaft 模式去 ZooKeeper 的那种那 kafka-manager 1.3.3.22 确实不太合适建议老老实实用 Kafka UI 或 CMAK。但如果你用的是 ZooKeeper-based Kafka版本在 0.10 到 2.7 之间那么 1.3.3.22 是性价比极高的选择。我的实际体验是它在几十个 broker、几百个 Topic 的集群规模下表现稳定Web UI 刷新速度够用内存占用控制在 1GB 以内。用它管理单个集群完全足够而且它每个集群支持独立配置 Kafka 版本极大方便了混部环境。对多数中小团队来说它比那些功能花哨但部署复杂的新工具好上手太多。提示下载 1.3.3.22 时尽量核对压缩包的哈希值。这个版本名流传广网上有不少第三方打包正规渠道一般来自 GitHub Releases 或企业内部镜像避免从来历不明的链接下载可执行文件。3. 完整部署过程从 zip 解压到界面亮起来3.1 环境准备里的三个关键点部署 kafka-manager 本身不需要装什么重型依赖它就是一个 Scala 写的 Play Framework 应用最终跑在 JVM 上。前提条件只有三个JDK 8 或 JDK 11。1.3.3.22 对 JDK 版本比较宽容JDK 8 最稳JDK 11 也没问题但我没试过 JDK 17不建议在生产的 JDK 17 上直接冒险。Kafka 集群和对应的 ZooKeeper。kafka-manager 会直接连接 ZooKeeper 读取 broker 信息所以 ZooKeeper 的连接串是必填项。一个可用的 web 端口默认 9000。如果你本机 9000 被占了后面启动参数里可以改。我之前踩过一个坑只安装 JRE 而不是 JDK。虽然 kafka-manager 运行起来只需要 JRE但如果后续你需要用它的 JMX 监控功能抓取指标最好保证本机有完整的 JDK否则有些 JMX 相关的类会加载异常控制台偶尔报 500。3.2 修改配置文件application.conf 里必须调整的内容解压下载的 kafka-manager-1.3.3.22.zip 后进入 conf 目录核心文件是 application.conf。官方默认配置可以直接跑但有三处我强烈建议你提前改掉否则后面早晚要返工。第一处是基本连接信息play.http.port9000 kafka-manager.zkhostszookeeper1:2181,zookeeper2:2181,zookeeper3:2181第二处是设置 kafka-manager 自身监听地址。默认是 0.0.0.0如果你部署在公网或办公网务必加一层防火墙或反向代理不要直接裸奔。想只本机访问可以改成 127.0.0.1配合 Nginx 反代最稳妥。第三处是修改应用密钥play.http.secret.keyyour-random-long-string默认值 yahoo 基本是众人皆知的暴露在外面会有安全风险。生产环境请生成一个长随机串填进去这个值会在 session 加密时用到。如果你要管理多个 Kafka 集群可以在 kafka-manager 的 Web UI 里添加不必改配置。配置文件里维护的是默认值UI 添加的集群信息会写进 ZooKeeper 中 kafka-manager 专属节点里。3.3 启动命令里的隐藏参数在 bin 目录下Linux 环境直接运行 kafka-managerWindows 运行 kafka-manager.bat。默认启动脚本里的内存参数是-Dpidfile.path/dev/null -Xms512m -Xmx512m -XX:UseG1GC我建议在脚本或环境变量 KAFKA_MANAGER_HEAP_OPTS 里加大初始堆内存。一个管理超过 5 个 Kafka 集群、Topic 数量上千的环境512MB 虽然能撑住但列表页刷新时会明显卡顿。调整到 1GB 到 2GB 后页面响应速度会舒服很多。完整启动命令可以这样写./bin/kafka-manager -Dhttp.port9000 -Dconfig.file/path/to/conf/application.conf启动后观察日志看到类似Application started的提示就说明成功了。然后用浏览器打开http://ip:9000首次进入会看到一个空列表页提示你添加第一个集群。注意如果页面完全打不开但进程还在先用netstat -lntp | grep 9000确认端口是否监听。很多时候是服务器防火墙没放行和程序本身无关。4. 添加集群和 Topic 管理那些 UI 上暗藏的小逻辑4.1 添加第一个集群时到底要填什么页面右上角点 Add Cluster会看到一堆表单。最关键的是一个叫 Cluster Zookeeper Hosts 的输入框填你 Kafka 用的 ZooKeeper 地址多个用逗号分隔。紧跟其后有一个 Kafka Version 下拉框别选错这个值对应你 Kafka broker 的真实版本。这个版本号为什么重要kafka-manager 会根据它决定走哪套协议去和 broker 通信。比如 Kafka 0.10 和 Kafka 2.0 的某些管理协议实现有差异选错了会导致 Topic 列表能看见但很多操作按钮置灰甚至创建分区失败。我的经验是勾选 Enable JMX Polling 之前先确认 broker 开了 JMX 端口没开的话勾了也只会在日志里刷一堆超时异常对整体功能没有致命影响但会拖慢刷新速度。Cluster 配置里还有几个选项比如 Enable Automatic Topic Creation我一般保持默认不勾选。自动创建 Topic 在某些业务场景下是灾难如果 Kafka 服务端本身设置了auto.create.topics.enabletrue这里再叠加一层自动创建线上很容易冒出各种拼写错误的 Topic。4.2 Topic 列表页的信息密度和操作误区添加完集群后进入 Topic 列表页你会看到每个 Topic 的分区数、副本数、分区leader分布、消息总量等。kafka-manager 的列表页会定时从 broker 同步元数据默认是每 30 秒刷一次可以在kafka-manager.consumer.properties里调。如果你看到列表数据不是最新别急着怀疑工具坏了先看刷新间隔。Topic 详情页是日常使用最频繁的地方。这里能手动调整分区数能触发生成分区优先副本选举还能查看某个分区的 leader 和 ISR 列表。我得提醒一点Reassign Partitions功能虽然好用但它是生成一份迁移候选 JSON真正执行还需要确认。它底层会调用 Kafka 的分区重分配 API这个过程是桶内副本逐步迁移不会锁写但如果线上 Topic 的写入压力很大迁移期间网络开销会明显上升。建议把迁移窗口选在业务低峰期而且一次不要同时执行太多 Topic。创建 Topic 页面相对简单填名称、分区数、副本数即可但下面那个Remote Log和Config折叠面板容易被忽略。大部分团队主题的retention.ms和max.message.bytes都是在这类界面里统一管理的没必要跑到 kafka-configs.sh 去敲命令。5. 生产环境里最有价值的消费者 Offset 监控5.1 从看不到到可视化的变化到底有多大Kafka 运维里最刚需的功能其实是消费者组监控。没有监控工具时你只能靠命令行kafka-consumer-groups.sh --bootstrap-server broker:9092 --group my-group --describe这条命令能输出每个 partition 的 current-offset 和 log-end-offset但它是瞬时快照没法看趋势。你想知道某个消费者是否长时间落后只能定时脚本采集后进 Grafana整体链路非常麻烦。kafka-manager 的 Consumer 页面把这个过程简化了。它通过 ZooKeeper 或 Kafka 的__consumer_offsets主题读取消费者 offset 信息在页面上用表格展示 group、topic、partition、当前 offset、log size、lag滞后量。一眼扫过去哪个组落后了几十万条哪个分区的 lag 在持续增长立刻能定位到。5.2 两个不同消费模型之间的显示差异kafka-manager 区分两类消费者基于 ZooKeeper 的旧版消费者和基于 Kafka 的新版消费者。新版消费者走__consumer_offsets主题需要 ConsumerGroupCommand 的权限才能读取如果你在 UI 上某个 group 显示 No consumers found先不要怀疑工具很可能是你的 Kafka 版本高于 2.0而 broker 端把group.initial.rebalance.delay.ms或 ACL 改动了导致 kafka-manager 不能正确获取 group 的状态。遇到这种情况我建议在集群的 server.properties 里单独给 kafka-manager 账号开启读权限或者把 kafka-manager 部署机器的 IP 放进 broker 的超级用户列表。这些都是常规操作不算 hack。如果你关心 lag 告警可以在 kafka-manager 的集群设置里勾选 Enable Alerting配置 webhook 地址。它的告警逻辑比较简单对 lag 阈值做轮询判断触发后发 HTTP 请求。虽然不如 PrometheusAlertManager 那样灵活但对没有额外监控组件的小团队来说完全可以当轻量告警系统用。5.3 消费者管理操作里的一个隐藏坑在 Consumer 页面里你会看到Generate Offset和View Offset之类操作按钮。Generate Offset 实际是让某个 group 的 offset 归零或重置到指定的时间点。我试过点击后页面表面上没有任何反馈但过一会儿消费者组 lag 全部变成 0 或者某个历史值。这里要特别小心这个动作等价于执行了kafka-consumer-groups.sh --reset-offsets。如果 group 还在生产中活跃消费重置 offset 轻则造成消息重复消费重则导致消费者进程异常退出。我在测试环境验证过对一个正在跑的 group 点击 Generate Offset 后同样一组消息被重复消费了两轮才恢复正常。所以线上操作前务必确认两件事第一这个 consumer group 是否可以停机第二你对 offset 要重置到什么位置有没有明确的预期。宁可先截图也别手滑。6. 真实踩坑记录改造集群时遇到的连接和显示问题6.1 问题一监控数据部分缺失broker 列表有灰色节点第一次部署完添加集群后我注意到某些 broker 节点在页面上呈灰色点进去看显示 No JMX data。正常现象因为 JMX 数据没收集到。kafka-manager 与 broker 的 JMX 连接走的是 JMX 端口不是 ZooKeeper 端口。Kafka 启动参数里如果没有配置JMX_PORT9999那 broker 根本不会开放 JMX 端口kafka-manager 自然拿不到监控数据。解决办法是给每个 broker 配上 JMX_PORT 并放行防火墙端口。改完不用重启 kafka-manager等下一个采集周期自然就显示正常了。如果你不想开 JMX也完全可以用 kafka-manager 管理 Topic 和分区只是看不到Broker 指标而已。6.2 问题二多个集群切换后消费组列表为空公司之前有套测试集群和生产集群共用一个 kafka-manager。切到生产集群后Consumer 列表始终空白但 Topic 列表正常。排查到最后的结论是生产集群的offsets.topic.replication.factor配置是 3而 kafka-manager 连接时用的kafka-manager.consumer.properties里默认 consumer 配置太弱无法稳定读取跨多副本的 offset 数据。调整方式是在 conf/consumer.properties 里明确写上bootstrap.serversbroker1:9092,broker2:9092,broker3:9092 exclude.internal.topicsfalse其中exclude.internal.topicsfalse很关键它确保工具能读取__consumer_offsets这个内部主题。很多空列表问题都是因为这个默认值导致的。6.3 问题三压力稍大时页面卡死CPU 飙高有段时间线上集群的 Topic 数涨到 2000 多个kafka-manager 的列表页开始转圈Java 进程 CPU 持续 100%。用 jstack 看了线程栈发现是 Play Framework 的默认线程池被元数据刷新任务堵死了。这个版本的kafka-manager.api-timeout-millis默认值偏小导致大量请求在等待 broker 响应时堆积。我把 application.conf 里这几个参数调整后问题缓解kafka-manager.api-timeout-millis10000 kafka-manager.api-unit-timeout-millis10000 kafka-manager.broker-view-update-period-seconds60 kafka-manager.broker-view-thread-pool-size8核心思路很简单把超时时间放宽把视图更新周期拉长给线程池更多并发槽位。不要指望 kafka-manager 能像监控大盘那样实时它更适合分钟级刷新。7. 关于安全加固和最后的经验总结如果你的 kafka-manager 所在机器能同时被开发和运维访问建议至少做两层保护第一层用 Nginx 做反向代理加 HTTP Basic Auth 或 OAuth2 登录第二层限制源 IP。kafka-manager 历史上没有爆出过特别严重的 RCE 漏洞但它管理着整个 Kafka 集群的写操作权限一旦被无关人员点几下重建分区、删 Topic 都是分分钟的事。它在设计之初没打算做成多用户权限系统所以谁都能操作这个问题一定要从外部解决。另外备份没什么玄学。kafka-manager 把集群配置和部分运行时状态存在 ZooKeeper路径通常是/kafka-manager。如果你要迁移 kafka-manager 机器只需要把 ZooKeeper 里这个节点数据保留好新机器部署后能自动识别原来的集群配置。这个特性我实际验证过省去了重新配一遍所有集群的麻烦。最后再说一个多数人不知道的小技巧kafka-manager 支持通过-Dconfig.file指定多个不同的配置文件也就是说你可以同时启动两个 kafka-manager 实例分别对应不同的集群组从而隔离权限边界。比如一台给开发看测试集群一台给运维管生产集群互不干扰。这个用法在一定程度上弥补了它没有细粒度权限的短板值得一试。kafka-manager 1.3.3.22 不是最新最潮的工具但在我接触过的所有 Kafka 管理界面里它是最稳、最不吃资源、最容易上手的一个。它不一定适合所有环境但只要你的 Kafka 还是 ZooKeeper 架构给它一次机会应该不会让你后悔。本文还有配套的精品资源点击获取