简介Kafka Manager是雅虎开源的一款Kafka集群管理工具提供集群监控、Topic管理、分区均衡、消费者Offset查看等能力。这份适用于Linux环境的Kafka-Manager-1.3.3.22已编译压缩包面向大数据运维工程师、Kafka使用与学习者解决Kafka集群可视化监控与管理配置繁琐的问题。包体采用zip格式整体约75.91MB解压后即可在目录下直接使用无需另行编译配合修改zookeeper地址、指定HTTP端口等简单调整即可通过浏览器访问管理界面。目前已有962人学习/下载适合需要快速搭建Kafka管理平台、降低集群运维门槛的中高级大数据从业者。资源主要便于读者在真实Linux环境中完成部署实践理解Kafka Manager的配置项、启动方式与监控逻辑是一份可直接落地使用的实战型工具包。1. 一个老版本 Kafka Manager为什么 1.3.3.22 还在被下载手头有一批 Kafka 0.10、0.11 旧集群的开发者多半都翻过 kafka-manager-1.3.3.22 这个包。明明这工具后来连名字都改了可老版本还在被反复下载原因是新版本对旧集群的兼容性反而没那么直接。我前阵子在一台内网机器上部署它前后折腾了两个晚上卡点不在解压和启动而在 Java 版本、ZooKeeper 地址和端口冲突。这篇笔记把实际踩过的路按步骤拆开从环境准备到验证跑通都写下来。适合正在维护旧 Kafka 集群又需要一个 Web UI 来管理 broker、topic 和消费者组的开发者。2. 环境准备JDK 8、ZooKeeper 和 kafka-manager-1.3.3.22 的版本搭配2.1 先看清版本约束JDK 8 是硬底线kafka-manager-1.3.3.22 基于 Play Framework 2.x 编译运行时对 Java 版本非常敏感。我第一次图省事直接用机器上已经装好的 JDK 11 去启动结果进程起来没到三秒就退出日志里一堆UnsupportedClassVersionError和NoSuchMethodError。后来换成 JDK 8 才正常。这里说的 JDK 8不区分具体发行版但要求是标准 JDK 8 的 64 位版本JRE 不行因为解压后的启动脚本里会读取JAVA_HOME而某些二进制工具需要javac同版本配套。java -version echo $JAVA_HOME which java这三条命令是排查第一步。输出里能看到类似openjdk version 1.8.0_xxx才是对的。如果JAVA_HOME没有设置启动脚本bin/kafka-manager会直接报错提示找不到 Java 环境所以就算which java有结果也要确认JAVA_HOME指向的是 JDK 8 的目录。提示如果你机器上同时装了多个 JDK别只改PATH要把JAVA_HOME和PATH一起改或者干脆在启动脚本前面显式导入环境变量否则切来切去很容易出现“命令行里是 8脚本里却是 11”的玄学问题。2.2 ZooKeeper 版本与连接地址规划kafka-manager-1.3.3.22 自己不保存业务数据它把配置信息、集群定义和调度任务的状态都存在 ZooKeeper 里。所以装它之前ZooKeeper 必须是可用状态而且这个 ZooKeeper 最好就是 Kafka 集群在用的那一个。如果集群的 broker 注册在zk1:2181,zk2:2181,zk3:2181这个地址下那 Manager 也要连同一个地址否则它会连到一个空的 ZooKeeper 上虽然能启动但添加集群时找不到对应的 broker。ZooKeeper 本身版本建议用 3.4.x 或 3.5.x我看到过用 ZooKeeper 3.6 接 kafka-manager-1.3.3.22 的情况会出现会话超时和节点数据格式不兼容的报错。这个旧版 Manager 对 ZooKeeper 的 API 调用比较保守没必要为了它去升级 ZooKeeper。# 在 Kafka 集群的任意一台 broker 机器上执行 bin/zookeeper-shell.sh zk1:2181 ls /brokers/ids这条命令用来验证 Kafka 的 broker 是否已经注册到 ZooKeeper。如果返回[0,1,2]这样的列表说明集群状态正常Manager 就可以接管。如果返回空或者报NoNodeException那说明你连错了 ZooKeeper或者 Kafka 集群本身就没起来。2.3 拿到 zip 包并校验文件完整性kafka-manager-1.3.3.22.zip 这个包通常通过网盘或内网共享传阅传输过程容易损坏。我一般先看文件大小然后算一下 SHA-256对比发布方给的校验值。没有校验值时也可以用unzip -t来测完整度这一步能避免后面解压到一半报CRC错误。sha256sum kafka-manager-1.3.3.22.zip unzip -t kafka-manager-1.3.3.22.zip unzip kafka-manager-1.3.3.22.zip -d /opt/kafka-manager-1.3.3.22解压后目录结构大致是bin/放启动脚本conf/放配置文件lib/放依赖 jar 包还可能有logs/目录没有自动创建需要手动建。我通常会先执行ls /opt/kafka-manager-1.3.3.22看一遍确认lib目录里有一个kafka-manager-1.3.3.22.jar这种名字的包。如果 jar 包缺失说明资源不完整后面启动会直接失败。注意解压路径里不要带中文和空格也不要放在权限受限的目录下。我见过有人解压到/home/user/我的工具/目录下结果启动脚本因为空格裂开控制台报错半天都找不到原因。统一放到/opt或/usr/local下最省心。3. 修改 application.conf四个必须改的参数3.1 zkhosts让 Manager 先找到 ZooKeeper解压之后配置核心就一个文件conf/application.conf。这是一个 HOCON 格式的文件不能直接放 JSON 语法也不能像 properties 那样只写keyvalue。第一处必须改的是zkhosts默认值往往写的是localhost:2181如果你的 ZooKeeper 不在本机这个值不改的话Manager 启动时就会尝试连自己本地的 2181结果可想而知。kafka-manager.zkhostszk1:2181,zk2:2181,zk3:2181这里填 ZooKeeper 的集合地址多个节点用逗号分隔。kafka-manager-1.3.3.22 本身会做会话重连如果第一个节点不可用它会尝试后面的节点。填完之后至少保证这些地址在 Manager 机器上能telnet zk1 2181通不然配置写了也白写。另外不要在地址后面加多余空格zk1:2181, zk2:2181这种带空格的写法会导致解析异常。3.2 kafka-manager-port别和 Web 服务撞车Manager 默认监听 9000 端口。生产环境上 9000 常常被其他管理面占用比如某个监控系统或者 Jenkins 之类的服务。所以端口一定要确认好否则启动时不报错但浏览器永远打不开页面。修改方式是这里http.port9000有的版本里这个参数可能在play.http.port或websocket.port后面要留意上下文。我一般习惯把端口改成带业务语义的比如19000同时在启动命令行里也带一份-Dhttp.port19000两处保持一致避免混乱。改完之后先查一下端口占用netstat -tlnp | grep 19000 ss -tlnp | grep 19000如果没有任何输出说明端口是空闲的。如果被占用要么换端口要么先处理占用进程不要硬启动。3.3 集群访问认证basicAuthentication 相关配置kafka-manager-1.3.3.22 自己带了一套简单的 HTTP Basic 认证。如果你不想让内网任何人直接打开管理页面就把它打开。配置位置同样在application.conf里。basicAuthentication.enabledtrue basicAuthentication.usernameadmin basicAuthentication.passwordyour-strong-password basicAuthentication.realmkafka-manager提示这个版本的密码是明文存放在配置文件里的所以千万别用生产环境里的重要密码也别把这个文件泄露出去。如果只是内网临时用也可以不开启认证但至少要在防火墙层面限制来源 IP否则谁都能对你的 Kafka 集群进行操作。开启认证后第一次打开页面会弹出一个登录框。这个登录框没有验证码暴力破解的风险是存在的所以我的做法是认证和防火墙一起用双保险。3.4 日志级别与 JVM 内存参数这个版本默认的 JVM 内存参数并不大当集群的 topic 数量较多或者启用了 Kafka 集群的 metrics 采集时Manager 内存容易吃紧。改内存的地方不在application.conf而在启动脚本bin/kafka-manager或者环境变量设置里。脚本内部会读取KAFKA_MANAGER_JAVA_OPTS这个变量我一般会在启动命令前显式指定。export KAFKA_MANAGER_JAVA_OPTS-Xmx2G -Xms512M -XX:UseG1GC-Xmx2G表示最大堆 2GB具体多大看机器内存一般 1.5GB 到 2GB 够用。-XX:UseG1GC是为了减少 GC 停顿在管理界面操作大量 topic 列表时体感更顺。日志级别方面默认的logger.kafka-managerINFO可以保留调试期间可以临时改成 DEBUG但生产环境不要开不然日志量会非常大。4. 启动服务bin/kafka-manager 脚本与端口分配4.1 前台启动看日志确认起得来第一次启动不要直接 nohup 后台先前台跑一次把日志打到控制台这样能第一时间看到异常。启动命令在解压目录下的bin/kafka-manager它本质上是一个 shell 脚本内部会拼出 java 命令并加载conf/application.conf。cd /opt/kafka-manager-1.3.3.22 bin/kafka-manager -Dconfig.fileconf/application.conf -Dhttp.port19000如果启动顺利日志里会出现类似Starting kafka-manager、Application started这样的行然后进程会一直停在终端里。此时不要急着关终端打开另一个窗口去 curl 一下端口。curl -i http://localhost:19000返回HTTP/1.1 200 OK就说明服务起来了。注意这里返回的是页面而不是 JSON所以 200 是正常的。如果页面跳转到登录页返回 302 也是正常的。4.2 后台启动与开机自启确认前台能跑通后就可以做成后台服务了。nohup 是常见做法但日志路径和 PID 文件要安排好方便以后停止和排错。nohup bin/kafka-manager -Dconfig.fileconf/application.conf -Dhttp.port19000 /var/log/kafka-manager/run.log 21 echo $! /var/run/kafka-manager.pid这里有个细节run.log的目录要提前建好否则重定向会失败导致进程没起来。echo $!把后台进程 PID 写到文件里后面停止用kill $(cat /var/run/kafka-manager.pid)。这种手动方式适合临时用如果要长期跑建议写 systemd service。cat /etc/systemd/system/kafka-manager.service EOF [Unit] DescriptionKafka Manager Service Afternetwork.target zookeeper.target [Service] Typesimple WorkingDirectory/opt/kafka-manager-1.3.3.22 ExecStart/opt/kafka-manager-1.3.3.22/bin/kafka-manager -Dconfig.fileconf/application.conf -Dhttp.port19000 Restarton-failure RestartSec10 EnvironmentKAFKA_MANAGER_JAVA_OPTS-Xmx2G [Install] WantedBymulti-user.target EOFsystemd 的好处是崩溃自动拉起而且日志直接进 journal用journalctl -u kafka-manager查起来方便。写Afterzookeeper.target只是一种依赖说明如果你的 ZooKeeper 不是 systemd 管理就把这一行删掉避免 unit 启动失败。4.3 配置防火墙和服务端参数Manager 部署在和 Kafka broker 不同的机器上时防火墙是第一个拦路虎。端口 19000 必须放行同时 Manager 出方向的 2181 端口也要通因为它要主动连 ZooKeeper。如果 ZooKeeper 开了 ACL 或 SASL 认证那还要在配置文件里补充认证信息这个版本对 SASL 的支持比较弱我一般建议直接简化网络策略避免把时间耗在 JAAS 配置上。firewall-cmd --permanent --add-port19000/tcp firewall-cmd --reload如果用 iptables记得规则顺序先放行后拒绝。另外如果 Kafka 集群本身开启了security.inter.broker.protocolSASL_PLAINTEXT或者SSLkafka-manager-1.3.3.22 还有一些额外参数要调但这属于比较深的改造通常内网测试环境很少用到这里不展开。5. 避坑指南部署现场最常踩的五个坑5.1 现象解压后bin/kafka-manager无法执行提示权限不够原因很简单zip 包解压后脚本的可执行权限可能会丢失尤其是从 Windows 制作的压缩包流传出来后权限位默认是644。解决方式是chmod x脚本文件同时确认 lib 目录下的 jar 包不需要执行权限。chmod x /opt/kafka-manager-1.3.3.22/bin/kafka-manager之后再看是不是还有Permission denied。这个问题很蠢但经常在第一次部署时出现我后来每次解压完都会先ls -l bin/瞄一眼权限位。5.2 现象启动秒退日志没有内容启动脚本执行后终端里什么都没有进程就消失了。这种情况多半是 Java 版本不对或者JAVA_HOME指向错误。前面说过JDK 11 及以上大概率会秒退。还有一种可能是配置文件的语法错误HOCON 解析失败时有些日志会打印到 stderr如果没重定向就会丢失。排查办法是强制打印日志到控制台bin/kafka-manager -Dconfig.fileconf/application.conf -Dhttp.port19000 21 | tee /tmp/km.log把 stderr 和 stdout 都合并看完整输出。如果看到exception和堆栈直接定位。另外检查conf/application.conf里是否有多余的逗号、括号没闭合这种错误在旧版本里报错信息不直观。5.3 现象页面能打开但添加集群一直转圈Manager 启动成功后登录页面能进点Cluster - Add Cluster填完信息按钮一直 loading最后超时失败。这个坑我踩过两次一次是 ZooKeeper 地址填错Manager 永远连不上注册中心另一次是填写的集群版本和实际版本不匹配。添加集群时有一个Kafka Version下拉框必须选择实际集群对应的版本。比如你的 broker 是 0.10.2那就要选0.10.2.x如果选了 0.9.0它会用错误的协议去拉取 broker 元数据导致转圈。解决先手动在 Manager 机器上执行zookeeper-shell.sh确认能连接到目标 ZooKeeper并确认/brokers/ids存在。如果连接正常再检查 Manager 日志看有没有Failed to get broker info的关键词。5.4 现象端口被占用改完配置后不生效有时候你以为改了conf/application.conf里的http.port但启动后页面打开的端口还是原来的。这是因为启动命令行中如果带了-Dhttp.port它优先于配置文件。如果你在命令行里写死了-Dhttp.port9000那配置文件是19000也没用。排查方式启动后用ss -tlnp | grep java看实际监听端口反过来推命令行参数。统一配置口径的做法是只改配置文件命令行不要带-Dhttp.port这样每次只维护一处不容易乱。5.5 现象启动后日志一直报SessionClosed或KeeperExceptionManager 连接 ZooKeeper 的会话一直在断重新连接又断日志类似Session expired、ConnectionLossException。原因一般是 ZooKeeper 服务端配置的maxClientCnxns或tickTime不适合 Manager 的长连接方式。这个旧版本 Manager 会建立多个长连接如果 ZooKeeper 的会话超时太短或者机器之间的网络有小抖动就会频繁掉线。解决调大 ZooKeeper 的会话超时参数在zoo.cfg里增加或修改maxClientCnxns200 tickTime4000修改后记得重启 ZooKeeper 服务。这个动作会影响整个集群最好在维护窗口做。如果不想动 ZooKeeper就从网络层面排查 Manager 到 ZooKeeper 是否有丢包用ping -c 100 zk1看延迟是不是稳的。6. 装完验证从 UI 到命令行确认服务健康6.1 浏览器走一遍核心流程进入登录页输入配置好的账号密码。如果没开认证直接进主界面。左侧导航栏有Cluster、Brokers、Topics等入口。先点Cluster - Add Cluster填好 ZooKeeper 地址选择对应的 Kafka 版本然后保存。正常情况下几秒后页面会跳转成集群概览能看到/brokers/ids里的 broker 数量并且每个 broker 的端口、机架、日志目录都会列出来。如果 broker 数量不对说明 Kafka 集群里可能有节点掉线或者 Manager 连到了错误的 ZooKeeper。然后在Topics页面点Create Topic建一个测试 topic分区和副本因子按集群实际规模填。创建成功后在列表里能看到这个 topic点击进去能看到分区分布、ISR 状态和消息日志大小。这就算基本跑通了。6.2 用 curl 和 jstat 做二次确认浏览器验证是给正常人看的命令行验证是给运维确认依据的。我用三行命令做最终确认curl -s http://localhost:19000/api/status | head -n 5 jstat -gcutil $(cat /var/run/kafka-manager.pid) 1000 3 tail -n 20 /var/log/kafka-manager/run.logcurl探活jstat看 JVM 的老年代使用率和 GC 情况日志里如果还有ERROR就要继续查。我自己后来养成的习惯是每次部署完这个过程必须走一遍尤其是jstat因为 Manager 刚启动堆占用都很小跑一两天后才容易暴露内存问题。希望这篇笔记能帮你少折腾几个晚上。本文还有配套的精品资源点击获取
