简介：Kafka-Manager 1.3.3.22 的已编译发行包，面向需要在 Linux 环境下快速搭建 Kafka 集群可视化管理界面的运维与大数据开发人员，省去源码编译环节，解压配置后即可接入现有 ZooKeeper 集群使用。压缩包为 zip 格式，整体约 75.91MB，内含编译产物、conf 配置目录及 bin 启动脚本等主要文件类型，其中 application.conf 用于指定 zkhosts 地址，bin 目录下的脚本负责以指定 HTTP 端口后台启动服务，目录结构完整、开箱即用。该资源已有 962 人学习下载，适合希望跳过繁琐构建流程、直接部署管理界面的中初级使用者。借助它，读者可快速获得一个可运行的 Kafka 集群监控入口，直观查看 Broker、Topic、分区与消费者组状态，并在此基础上完成日常运维与故障排查，同时保留配置与启动脚本便于按环境调整端口和集群地址。
1. 从一次 Kafka 集群“看不见”的事故说起：为什么我坚持用 kafka-manager-1.3.3.22 做可视化管理
去年冬天排查一个消费积压问题，集群里十几个 broker、上百个 topic，运维同事只能靠kafka-topics.sh --describe一条条翻，翻到第三屏就迷路了。后来我在一台跳板机上装了 kafka-manager-1.3.3.22，把集群接进去，topic 的分区分布、ISR 收缩、消费组 lag 一眼就能看到，那次事故的根因十分钟内就定位了。kafka-manager 这个工具在 Kafka 运维圈子里几乎是标配，1.3.3.22 是 1.3.x 系列里比较稳的一个打包版本，适合还在用 JDK 8、Kafka 0.10 到 2.x 的老集群环境。装不好会怎样？最常见的就是启动报NoSuchMethodError或者页面能打开但连不上集群，看着像玄学，其实都是版本和配置没对齐。这篇笔记面向需要给 Kafka 集群配一套可视化管理界面的开发者，从环境准备一路写到验证跑通，照着走能少踩几个坑。
2. 装前把环境列清楚：JDK、Scala 与 kafka-manager-1.3.3.22 的版本对应关系
kafka-manager 是 Scala 写的 Play Framework 应用，打包成 zip 之后自带启动脚本，但它对 JDK 版本和 Kafka 版本都有要求。1.3.3.22 这个版本编译时用的是 Scala 2.11，运行需要 JDK 8，JDK 11 及以上会出现模块系统相关的启动异常。这一章先把版本矩阵、目录结构和依赖项讲透，后面安装才不会返工。
2.1 版本矩阵：JDK 8 是硬门槛，Kafka 版本要匹配
我一般会先确认三件事：JDK 版本、Kafka 集群版本、以及目标机器上有没有装 sbt（不需要，zip 包已经带好编译产物）。下面这张表是我在多个环境里验证过的组合，供参考：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8.0_202 及以上 | 1.3.3.22 在 JDK 8 上最稳，JDK 11 启动会报Unsupported class file major version |
| Kafka | 0.10.0 至 2.4.x | 1.3.3.22 对 2.5 之后的版本兼容性一般，新集群建议先小范围试 |
| ZooKeeper | 3.4.x | kafka-manager 通过 ZK 读取集群元数据，ZK 版本要和 Kafka 自带的一致 |
| 操作系统 | CentOS 7 / Ubuntu 18.04 | 主要是启动脚本里的 shell 语法，老系统更省心 |
提示：如果你的集群是 Kafka 2.8 或 3.x，kafka-manager 1.3.3.22 可能读不到部分新协议字段，页面上的 topic 列表会不全。这种情况要么降级管理工具，要么换用社区维护的 CMAK 分支，但那是另一套东西了。
版本选错最典型的翻车现场是：JDK 11 下执行bin/kafka-manager直接抛java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter，因为 JDK 11 移除了 JAXB 模块。遇到这个别急着改代码，先把JAVA_HOME指回 JDK 8 就行。
2.2 目录结构与依赖项：zip 包里到底有什么
kafka-manager-1.3.3.22.zip 解压后是一个kafka-manager-1.3.3.22目录，里面几个关键路径需要提前知道：
kafka-manager-1.3.3.22/ ├── bin/ │ └── kafka-manager # 启动脚本，核心入口 ├── conf/ │ ├── application.conf # 主配置文件，集群连接、端口、ZK 地址都在这 │ └── logback.xml # 日志配置 ├── lib/ # 所有依赖 jar，不需要额外下载 └── share/ # 文档和示例这个包是“开箱即用”型，lib/里已经打好了 Play Framework、Akka、ZK 客户端等依赖，不需要联网拉 jar。但有两个隐性依赖：一是机器上要有可用的JAVA_HOME，二是启动脚本会调用java命令，PATH 里必须能找到。我见过有同事在容器里装，基础镜像只带了 JRE 没带java软链，脚本直接报java: command not found，排查了半天。
2.3 端口与资源规划：8080 不是随便占的
kafka-manager 默认监听 9000 端口，但 1.3.3.22 的application.conf里play.http.port默认值经常被改成 8080，和很多 Web 服务冲突。装之前先确认端口占用：
# 检查 9000 和 8080 是否被占用 ss -lntp | grep -E ':(9000|8080)\b'如果输出为空说明端口空闲。资源方面，单节点管理几十个 topic 的集群，给 2C4G 足够；如果 topic 上千、分区上万，建议 4C8G，因为页面加载时会一次性拉取全量元数据，内存小了容易 OOM。JVM 堆参数在bin/kafka-manager脚本里通过KM_HEAP_OPTS控制，默认是-Xms1024m -Xmx1024m，大集群可以调到 2G。
3. 安装与配置：从解压到 application.conf 的逐项落地
环境确认完就可以动手了。这一章按“解压 → 配 JDK → 改 application.conf → 启动”的顺序走，每一步给出命令和参数说明。中间会重点讲application.conf里几个容易写错的配置项，以及 ZK 地址和集群别名的对应关系。
3.1 解压与目录归位：别放在 /tmp 下
先把 zip 包传到目标机器，我一般放在/opt下，方便统一管理：
# 上传后解压到 /opt cd /opt unzip kafka-manager-1.3.3.22.zip # 确认目录结构 ls -l /opt/kafka-manager-1.3.3.22/bin/kafka-manager解压后给启动脚本加执行权限：
chmod +x /opt/kafka-manager-1.3.3.22/bin/kafka-manager这里有个血泪经验：不要把解压目录放在/tmp或用户 home 下。kafka-manager 运行时会往logs/和RUNNING_PID写文件，/tmp可能被系统清理策略删掉，导致进程莫名其妙挂掉。放在/opt或/data这类固定路径下最稳。
3.2 指定 JDK 8：JAVA_HOME 的两种写法
启动脚本会优先读环境变量JAVA_HOME，如果没设就用 PATH 里的java。我习惯在启动前显式指定，避免机器上装了多个 JDK 时选错：
# 临时指定，只对当前 shell 生效 export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.202.b08-1.el7_6.x86_64 export PATH=$JAVA_HOME/bin:$PATH # 验证版本 java -version输出应该是java version "1.8.0_202"这类。如果机器上没有 JDK 8，CentOS 7 下可以这样装：
yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-develdevel包不是必须的，但有些环境里jps命令依赖它，排查进程时用得上。装完用alternatives --config java确认默认指向 1.8。
3.3 application.conf 关键配置：ZK 地址、集群别名与端口
配置文件在conf/application.conf，1.3.3.22 的默认内容里有一大段注释，实际需要改的就几项。我一般先备份再改：
cd /opt/kafka-manager-1.3.3.22 cp conf/application.conf conf/application.conf.bak然后编辑application.conf，核心配置如下：
# 管理界面监听端口，默认 9000，冲突时改成 9001 等 play.http.port=9000 # 基础 ZK 地址，kafka-manager 自身状态存这里 kafka-manager.zkhosts="zk1.example.internal:2181,zk2.example.internal:2181" # 是否启用基本认证，内网环境可以先关 kafka-manager.basicAuthentication.enabled=false # 集群配置，别名和 ZK 地址一一对应 kafka-manager.clusters = [ { name = "prod-cluster" zkHosts = "zk1.example.internal:2181,zk2.example.internal:2181" kafkaVersion = "2.4.0" } ]几个参数说明：play.http.port是 Web 端口，改完要确认防火墙放行；kafka-manager.zkhosts是 kafka-manager 自己存元数据的 ZK，可以和 Kafka 集群共用，也可以单独一套；clusters里的name是页面上显示的集群别名，zkHosts指向 Kafka 集群使用的 ZK，kafkaVersion要填集群实际版本，填错会导致部分指标读不出来。
注意：
zkHosts里的地址不要带chroot路径（比如:2181/kafka），1.3.3.22 对 chroot 的支持有 bug，带路径会连不上。如果 Kafka 集群确实用了 chroot，需要在 ZK 层面做一次映射，或者升级到修复该问题的版本。
3.4 启动与后台运行：nohup 与 PID 文件
配置改完就可以启动。前台启动方便看日志：
cd /opt/kafka-manager-1.3.3.22 bin/kafka-manager -Dconfig.file=conf/application.conf看到Listening for HTTP on /0.0.0.0:9000说明起来了。生产环境用后台方式：
nohup bin/kafka-manager -Dconfig.file=conf/application.conf > logs/startup.log 2>&1 & echo $! > RUNNING_PID-Dconfig.file显式指定配置文件路径，避免脚本从 classpath 里读到旧配置。RUNNING_PID是 Play 框架约定的 PID 文件，停止时用kill $(cat RUNNING_PID)。如果启动后进程立刻退出，先看logs/startup.log最后 50 行，八成是端口占用或 ZK 连不上。
4. 避坑与排查：kafka-manager 1.3.3.22 最常见的五类翻车
装这个工具踩过的坑比装 Kafka 本身还多，下面五条是我在不同环境里反复遇到的，按“现象 → 原因 → 解决”记下来，遇到时直接对号入座。
4.1 启动报 NoSuchMethodError 或 ClassNotFoundException
现象：执行启动脚本后立即退出，日志里出现java.lang.NoSuchMethodError: scala.Predef$.refArrayOps或ClassNotFoundException: play.api.Configuration。
原因：机器上存在多个 Scala 或 Play 版本，CLASSPATH被其他应用污染，或者lib/目录被误删了部分 jar。
解决：先确认lib/下 jar 数量完整（1.3.3.22 大约 100 多个），再检查启动脚本有没有被改过。最稳妥的做法是在干净 shell 里启动，不继承其他应用的CLASSPATH：
env -i JAVA_HOME=$JAVA_HOME PATH=$PATH bin/kafka-manager -Dconfig.file=conf/application.conf4.2 页面能打开但集群列表为空
现象：浏览器访问http://ip:9000正常，但 Add Cluster 之后看不到 topic，或者提示Error connecting to ZooKeeper。
原因：application.conf里的zkHosts写错，或者 Kafka 集群的 ZK 开了 ACL 而 kafka-manager 没带认证信息。
解决：先在机器上用zkCli.sh连一下配置里的 ZK 地址，确认能ls /brokers/topics。如果 ZK 有 ACL，需要在application.conf里加kafka-manager.zkhosts对应的认证配置，1.3.3.22 支持zkSecurityEnabled=true加 JAAS 文件的方式，具体看conf/下的示例。
4.3 消费组 lag 显示为 0 或负数
现象：Consumer 页面里 lag 列全是 0，或者出现负数，和kafka-consumer-groups.sh的结果对不上。
原因：kafkaVersion填得比实际集群版本高，kafka-manager 用了新协议的 offset 读取方式，老集群返回空。
解决：把clusters里的kafkaVersion改成集群真实版本，比如实际是 1.1.0 就填1.1.0，别图省事填2.4.0。改完重启生效。
4.4 启动后端口被占用但进程还在
现象：日志报Address already in use，但ps能看到 kafka-manager 进程，页面打不开。
原因：上一次启动的进程没退干净，RUNNING_PID文件残留，新进程绑端口失败但父进程没退出。
解决：先kill $(cat RUNNING_PID)，确认端口释放后再启动。如果 PID 文件丢了，用ss -lntp | grep 9000找到占用进程手动 kill。
4.5 大集群页面加载超时
现象：topic 数量超过 2000 时，首页转圈几十秒后 502，日志里AskTimeoutException。
原因：默认 Akka 超时时间太短，全量元数据拉取来不及。
解决：在application.conf里调大超时：
kafka-manager.akka.ask-timeout=60s同时把 JVM 堆调到 2G，KM_HEAP_OPTS="-Xms2048m -Xmx2048m"，再重启。
5. 装完怎么验证跑通：三步确认法与我的固定习惯
装完不等于跑通，我一般用三步确认：进程在、端口通、数据对。这三步走完才敢说这套环境能交付。
5.1 进程与端口：先确认服务活着
# 确认进程存在 ps -ef | grep kafka-manager | grep -v grep # 确认端口监听 ss -lntp | grep 9000两条命令都有输出才算第一步通过。如果进程在但端口没监听，回看logs/startup.log里的Listening for HTTP那行有没有出现。
5.2 页面与接口：用 curl 做无头验证
浏览器打开之前，先用 curl 确认 HTTP 层正常：
# 返回 200 且内容包含 kafka-manager 字样 curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:9000/ # 查看首页标题 curl -s http://127.0.0.1:9000/ | grep -i "kafka manager"返回200说明 Web 服务正常。如果返回303跳转到登录页，说明开了 basic auth，属于正常现象。
5.3 数据核对：拿一个 topic 和命令行对账
最后一步最关键：在页面上找一个 topic，记下分区数和 ISR 数量，然后用命令行核对：
# 以 prod-cluster 里的 test-topic 为例 kafka-topics.sh --bootstrap-server kafka1:9092 --describe --topic test-topic页面显示的分区数、副本数、ISR 应该和命令输出一致。再进 Consumer 页面看一个活跃消费组的 lag，和kafka-consumer-groups.sh --describe的结果对比，误差在合理范围内（秒级刷新）就算通过。三步都过了，这套 kafka-manager 1.3.3.22 就算真正跑通了。
从那以后我每次装完 kafka-manager，都强制走一遍“进程 → 端口 → 数据对账”这三步，哪怕是在测试环境也不敢省，因为前两步只能证明它活着，第三步才能证明它真的读到了集群。希望这套流程帮到你，少在版本和 ZK 地址上翻车。
本文还有配套的精品资源，点击获取
