systemd 启动zk kafka

一、需求介绍

有个很常见的需求:
线下环境中,我想在云主机(或者物理机)上安装 Zookeeper 和 Kafka,两个进程在因为某种异常退出后,能够自动尝试重启。要实现该需求有很多种方案:

  • 搞个脚本定时获取进程,若发现进程不在了,就自动重启
  • 使用Docker 或者 K8 的管理能力【最为推荐】
  • 使用systemd的管理能力

本文讲述的是在centos上使用systemd管理zookeeper 和 kafka.

二、首先安装ZK 服务

1、定义[Unit]文件(service文件)


vim /etc/systemd/system/zookeeper.service

[Unit]
Description=zookeeper.service
After=network.target

[Service]
Type=forking

# 第一行设置日志目录,如果没有设置,默认是当前目录,对有的用户来说,可能没有权限。
Environment=ZOO_LOG_DIR=/apps/svr/apache-zookeeper-3.5.9-bin/
# 第二行是配置环境变量,systemd用户实例不会继承类似.bashrc中定义的环境变量,所以是找不到jdk目录的,而zookeeper又必须有。
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/apps/svr/jdk1.8.0_102/bin:/root/bin
ExecStart=/apps/svr/apache-zookeeper-3.5.9-bin/bin/zkServer.sh start 
#ExecStop=/apps/svr/apache-zookeeper-3.5.9-bin/bin/zkServer.sh stop
#ExecReload=/apps/svr/apache-zookeeper-3.5.9-bin/bin/zkServer.sh restart
PIDFile=/data/zookeeper/zookeeper_server.pid
# 只要不是通过systemctl stop来停止服务,任何情况下都必须要重启服务,默认值为no
Restart=always
# 重启间隔,比如某次异常后,等待5(s)再进行启动,默认值0.1(s)
RestartSec=10
# StartLimitInterval: 无限次重启,默认是10秒内如果重启超过5次则不再重启,设置为0表示不限次数重启
StartLimitInterval=0
[Install]
WantedBy=multi-user.target

2、处理已有ZK进程
如果当前主机上已有ZK 进程了,zookeeper.service会启动不成功,所以手动干掉 ZK 进程
jps |grep 'Quo' | awk '{print $1}' |xargs kill

3、执行命令

systemctl daemon-reload
systemctl enable zookeeper
systemctl start zookeeper

4、可以利用systemd自带命令来查看服务状态以及错误日志

systemctl status kafka-zookeeper -l 

5、还可测试下 systemd是否真如预期那样能在Zk进程挂了之后自动将其拉起:
将ZK 进程 kill ,ZK进程退出,等待片刻,看 ZK 进程是否重新出现

三、安装Kafka服务

1、定义service文件

-- ------------------------------
vim /etc/systemd/system/kafka.service

[Unit]
Description=Apache Kafka server (broker)
After=network.target zookeeper.service

[Service]
Type=forking
Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/apps/svr/jdk1.8.0_102/bin:/root/bin
ExecStart=/apps/svr/kafka_vms-2.7.0/bin/kafka-server-start.sh -daemon /apps/svr/kafka_vms-2.7.0/config/server.properties 
# 只要不是通过systemctl stop来停止服务,任何情况下都必须要重启服务,默认值为no
Restart=always
# 重启间隔,比如某次异常后,等待5(s)再进行启动,默认值0.1(s)
RestartSec=10
# StartLimitInterval: 无限次重启,默认是10秒内如果重启超过5次则不再重启,设置为0表示不限次数重启
StartLimitInterval=0
LimitNOFILE=265535

[Install]
WantedBy=multi-user.target

2、若当前已经kafka进程,则可能启动kafka服务失败

jps |grep -i Kafka | awk '{print $1}' |xargs kill

3、更新 systemd,启动kafka服务

systemctl daemon-reload
systemctl enable kafka
systemctl start kafka

4、查看状态

systemctl status kafka -l

这里要说下 配置 LimitNOFILE=265535, 如果将一个 kafka做成了一个 systemd service,那么修改 /etc/sysctl.conf /etc/security/conf的配置未必能够生效。想要验证的话,查看/proc/<kafka pid>/limits中的Max Open Files即可,为啥呢?怀疑kafka service启动时,使用了父进程的 NOFILE配置。

四、参考

  • systemd 使用 https://zhuanlan.zhihu.com/p/56889721
  • Kafka Zookeeper systemd :https://gist.github.com/dyoung522/6f7aab567f70f67030ae4ee0191933c0
  • http://www.ruanyifeng.com/blog/2016/03/systemd-tutorial-commands.html
<think>嗯,用户问的是Kafka启动失败的原因和解决方案。我需要根据提供的引用资料来整理可能的原因和对应的解决办法。首先,引用[1]提到日志目录权限问题,这应该是常见的问题之一。Kafka需要写入日志目录,如果权限不对或者目录不存在,肯定会启动失败。然后是引用[2]和[3],虽然主要讲高延迟和消息丢失,但监控集群状态可能也会涉及到启动问题,比如配置错误或者资源不足。引用[4]提到的事务和磁盘顺序读写,可能和日志存储有关,但启动失败更可能直接和配置、权限相关。引用[5]关于重复消费的问题,暂时和启动失败关系不大。 接下来,我需要检查用户提供的引用内容,找出所有可能的原因。引用[1]明确说了日志目录权限问题,解决办法是检查目录存在性和权限。另外,可能还有其他原因,比如端口被占用,ZooKeeper连接问题,内存不足,配置文件错误等。这些在提供的引用中没有直接提到,但根据常见问题,可能需要补充。不过用户提供的引用中,除了引用[1],其他的可能相关度较低,但引用[3]提到监控集群状态,可能配置文件错误导致的问题需要检查配置是否正确。 另外,用户给出的引用[4]中提到Kafka的事务处理和磁盘顺序读写,可能磁盘空间不足也是一个原因,但用户的问题里没有提到,但根据常识,磁盘空间不足也可能导致启动失败。不过根据提供的引用,可能没有这个信息,需要判断是否应该包含。不过引用[1]提到的是日志目录的写入权限,可能磁盘空间不足属于类似问题,但不在提供的引用里,所以可能用户给的资料里没有,这时候是否需要添加?根据用户的要求,回答要尽量真实可靠,引用站内的引用,所以可能只应基于提供的引用内容。不过引用[1]还提到确保日志目录存在,所以目录不存在也是一个原因。 综上,可能的原因有: 1. 日志目录权限问题(引用[1]) 2. ZooKeeper连接失败(可能来自常识,但用户给的引用中没有明确提到,不过引用[1]是关于ZooKeeper和Kafka集群启动失败的,可能包括ZooKeeper的问题) 3. 配置文件错误(引用[3]提到监控配置,可能检查配置) 4. 端口被占用(常识,但用户引用中没有) 5. 内存不足(常识,可能) 但根据用户提供的引用,引用[1]提到了日志目录权限和存在性,引用[3]提到监控配置,引用[4]提到配置中的事务处理相关,但可能不直接相关。所以需要优先处理引用中的内容,再补充可能的其他原因。 因此,整理回答的结构: 首先列出原因和解决方案,每个原因对应引用中的支持。比如: 1. 日志目录权限或存在性问题(引用[1]) 2. ZooKeeper集群不可用(可能引用[1]中的ZooKeeper问题) 3. 配置文件错误(引用[3]的监控配置可能涉及配置检查) 4. 端口冲突 5. 内存不足/JVM配置错误 但需要确认是否有对应的引用支持。比如ZooKeeper的问题在引用[1]的标题里提到,但具体内容可能没有详细说明,不过用户引用[1]的标题是“ZooKeeper和Kafka集群启动失败问题解析与解决方案”,所以可能里面提到ZooKeeper的问题,但用户提供的引用内容中引用[1]的具体内容只有日志目录权限的问题。所以可能需要假设ZooKeeper的问题也是一个原因,解决方案可能需要检查ZooKeeper是否正常运行,配置是否正确。 另外,引用[4]提到了Kafka配置中的日志目录设置,可能还有其他的配置参数错误,比如broker.id重复,listeners配置不正确等,这些都属于配置文件错误,可以归类到配置文件错误中。 因此,可能的解决方案步骤: 1. 检查日志目录权限和存在性(引用[1]) 2. 检查ZooKeeper连接(基于引用[1]的标题) 3. 检查配置文件正确性(如broker.id、listeners等)(引用[3]可能涉及配置检查) 4. 检查端口占用(如9092端口是否被占用) 5. 检查内存和JVM设置(比如-Xmx参数是否合理) 但需要根据用户提供的引用内容来对应。例如,引用[1]明确提到了日志目录的问题,引用[3]提到监控集群状态,可能涉及配置检查,而引用[4]提到了配置中的日志目录设置,可能支持配置文件检查这一点。 所以最终的答案应该包括: - 日志目录问题(存在性和权限) - ZooKeeper连接问题 - 配置文件错误(如server.properties中的配置) - 端口被占用 - 内存不足或JVM配置错误 每个点都需要对应的解决方案,并引用相应的引用来源。比如日志目录引用[1],配置文件检查引用[3],ZooKeeper问题可能引用[1]的标题,但具体内容中没有详细说明,可能需要结合常识,但用户可能希望答案基于提供的引用,所以可能ZooKeeper的问题在引用中没有详细说明,但标题提到了,所以需要包含吗? 比如,引用[1]的标题是“ZooKeeper和Kafka集群启动失败问题解析与解决方案”,但具体内容只提到了Kafka的日志目录问题。因此,可能用户提供的引用内容中关于ZooKeeper的部分没有详细说明,所以可能需要假设ZooKeeper的问题也是其中一个原因,但解决方案可能需要检查ZooKeeper是否运行,配置是否正确,但引用中没有给出具体方法。这时候是否需要包含? 根据用户提供的引用,可能只有日志目录权限问题有具体说明,其他原因需要结合常识,但用户要求回答中引用的段落末尾添加引用标识,所以可能其他原因无法引用,但可能引用[1]的标题提到ZooKeeper,所以可能可以引用[1]来指出ZooKeeper的问题,但具体解决方案可能需要用户自己检查ZooKeeper。 因此,可能回答的结构如下: 1. 日志目录权限或路径错误(引用[1]) - 确保目录存在,权限正确 2. ZooKeeper集群不可用(引用[1]的标题,但具体内容没说明,所以可能无法直接引用) - 检查ZooKeeper是否正常运行,配置是否正确 3. 配置文件错误(引用[3]提到监控配置,可能需要检查配置) - 检查server.properties中的配置,如broker.id、listeners等 4. 端口冲突 - 检查端口是否被占用 5. JVM内存配置问题 - 调整-Xmx参数 但需要尽可能引用用户提供的资料。例如,引用[3]提到“监控Kafka集群状态:使用Kafka提供的工具监控集群的运行状态,及时发现问题”,这可能建议在解决方案中查看日志和使用监控工具,所以在解决方案中可以建议检查日志,查看错误信息,这可能对应到具体的错误原因,如ZooKeeper连接失败或端口占用。 总结,用户的回答需要基于提供的引用内容,所以主要的原因包括: - 日志目录权限问题(明确引用[1]) - ZooKeeper问题(引用[1]标题提到,但内容未详细说明) - 配置文件错误(引用[3]和[4]可能涉及配置检查) - 其他如端口、内存等(常识部分,但无法引用) 因此,在回答中,优先列出有引用支持的原因,再补充其他可能原因,并尽可能关联引用。 例如: 可能原因: 1. 日志目录权限或路径错误 [^1] - 检查日志目录是否存在,权限是否正确 2. ZooKeeper连接失败 [^1] - 检查ZooKeeper集群状态和配置 3. 配置文件错误 [^3][^4] - 检查server.properties中的配置项,如broker.id、listeners、zookeeper.connect等 4. 端口冲突 - 检查Kafka使用的端口(如9092)是否被占用 5. JVM内存配置问题 - 调整JVM参数,避免内存不足 其中,ZooKeeper连接失败可以关联引用[1],因为引用[1]的标题提到了ZooKeeper和Kafka启动失败的问题,但具体内容没有详细说明。因此可能需要用引用[1]来支持这一点,但用户可能希望更精确的引用。如果引用[1]的具体内容没有提到ZooKeeper,可能需要省略,或者仅作为补充。 可能更安全的做法是,仅将明确提到的原因用引用标注,其他原因作为补充。例如: 明确引用[1]提到的日志目录问题,其他原因可能无法引用,但根据常见问题,仍需列出,但可能不标注引用,或者寻找可能的关联。例如,引用[3]提到监控集群状态,可以建议查看日志,这可能帮助诊断问题,如ZooKeeper连接问题或端口冲突。 最终,回答结构可能如下: ### Kafka启动失败的常见原因及解决方案 1. **日志目录权限或路径错误** Kafka需要写入配置的日志目录。若目录不存在或权限不足,启动将失败。 **解决方案**: - 检查`server.properties`中`log.dirs`配置的路径是否存在 - 确保Kafka进程拥有该目录的读写权限,例如: ```bash chmod -R 755 /path/to/kafka-logs chown -R kafka_user:kafka_group /path/to/kafka-logs ``` 引用 2. **ZooKeeper连接失败** Kafka依赖ZooKeeper管理元数据。若ZooKeeper未启动或配置错误,Kafka无法启动。 **解决方案**: - 检查ZooKeeper集群是否正常运行(`zkServer.sh status`) - 确认`server.properties`中`zookeeper.connect`的地址和端口正确(例如`localhost:2181`) - 查看ZooKeeper日志排查连接问题 3. **配置文件错误** 错误的配置项(如重复的`broker.id`、无效的监听地址)会导致启动失败。 **解决方案**: - 使用`kafka-configs.sh`验证配置 - 检查关键配置项: ```properties broker.id=0 # 必须唯一 listeners=PLAINTEXT://:9092 advertised.listeners=PLAINTEXT://your_hostname:9092 ``` - 推荐使用监控工具(如Kafka Manager)检查配置健康状态 引用 4. **端口冲突** Kafka默认使用9092端口,若端口被占用则启动失败。 **解决方案**: - 通过命令查找占用端口的进程并终止: ```bash lsof -i :9092 kill -9 <pid> ``` - 或修改`server.properties`中的`listeners`配置更换端口 5. **内存/JVM配置问题** 内存不足或JVM参数错误可能导致进程崩溃。 **解决方案**: - 调整`kafka-server-start.sh`中的内存参数,例如: ```bash export KAFKA_HEAP_OPTS="-Xmx2G -Xms2G" ``` - 避免给JVM分配超过物理内存的资源 6. **其他常见问题** - **磁盘空间不足**: 检查日志目录所在磁盘的剩余空间 - **版本不兼容**: 确保Kafka与ZooKeeper版本兼容 **诊断建议**: - 查看Kafka启动日志(默认位于`logs/server.log`),根据错误信息精准定位问题 引用 - 使用`systemctl status kafka`(若通过systemd管理)查看服务状态
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值