# 问题描述 进行ELK服务器的变更，部署好新的kafka服务后无法启动服务，导致日志无法正常输出查看 # 问题分析 通过查看kafka日志，kafka/logs/server.log或系统日志journalctl -xeu kafka，可以看到/brokers/ids/0存在导致了服务异常。  kafka的broker id在server.properties中配置，一个环境内是唯一的，不允许重复。  通过server.properties确定zk的地址，查询对应报错的节点，能确定老的kafka服务还在运行中，占用了为0的id，所以新服务器的kafka无法启动。  # 解决办法 可以停止老的kafka服务，再次启动新kafka，或通过zk删除老节点信息也可以让新kafka启动完成注册。  注意：如果新老版本kafka不同，可能单独删除/brokers节点，依旧会有部分值不匹配的报错，这种情况需要删除kafka注册到zk中的所有值，或者修改kafka的注册路径。 kafka注册节点统计如下： admin, brokers, cluster, config, consumers, controller_epoch, feature, isr_change_notification, latest_producer_id_block, log_dir_event_notification  ## 注意事项 对于更换ELK的场景，mc中相关配置修改（kafka和es的ip）后需要重启mservice相关服务才生效，操作后如果还是无法正常输入日志，可以通过社区搜索“monitor日志排查思路”，此处不再累述。 # 其他报错场景 ## Cluster ID不匹配 之前正常使用的kafka服务无法启动， 查看kafka日志，Cluster ID不匹配  常见原因是运行kafak在该目录下创建了一些主题信息，后来清理了zookeeper的数据及日志后，但是没有对kafka-logs目录位置下的数据进行清理，导致新启的kafka服务The Cluster ID 与 meta.properties的旧的cluster.id匹配不上，所以报错。解决方案删除kafka-logs目录后重启kafka即可重新匹配。 ## 访问被拒绝 升级kafka后无法启动  目前安装器都会使用kafka的用户身份启动kafka服务，升级过程中新版本kafka解压后忘记修改文件权限导致的无权访问报错路径，将kafka文件及文件夹所有者修改为kafka（现场确认升级前文件的所有者）即可。