一次kafka节点异常掉线问题排查，用到监控方恨少....

前段时间平平无奇的一个中午，11:10左右，再过一会就是日常下楼吃午饭的时间。嗯，很平常。

突然，收到了kafka端口异常的告警通知，心里咯噔一下，别是节点挂了吧裂开：

通常情况下，如果不是3节点+3副本的kafka集群，单节点挂掉没有什么可担心的，短时间内不会影响服务运行。

但我一看ip，就想起这个集群确实是3节点+3副本的，当场就裂开了。

正好，这个时候也接到了业务请求kafka 499的超时告警。得，这下铁定挂了没跑了。

上机器查grep了下，果然kafka server的进程没有了。

先按照启动命令把服务先启动起来，避免服务长时间不可用，报错日志可以等会再排查。

kafka-server-start -daemon /etc/kafka/server.properties

但是发现启动不了。过不了几秒，进程就自行消失了。这下只能先去日志里看看到底是什么问题，居然重启都无法解决。

org.I0Itec.zkclient.exception.ZkTimeoutException: Unable to connect to zookeeper server 'xx.x.x.xx:2181,xx.x.x.xx:2181,xx.x.x.xx:2181' with timeout of 6000 ms

咦，怎么zk出问题了？赶忙去telnet zk的接口，发现3台节点都可以连通，并且监控组件显示zk节点都是live的。

但是想要查看zk内的数据时，却同样出现了连接报错：

没什么特别好的办法，只能先重启zk，看看能不能解决zk假死的问题。

先后重启了follower和leader节点后，zk至少可以访问通，可以查看数据了。

再次尝试启动kafka节点，这次在日志里发现了关键报错信息：No space left on device

看到这里瞬间恍然大悟。退出日志后，查看了下磁盘占用，数据盘使用率果然已经100%，罪魁祸首找到了！

再次通过磁盘大小占用率分析，定位到了罪魁祸首（用于binlog存储的某topic）。联系推送方进行数据清理后，kakfa服务恢复正常。

服务不可用时间大约半个小时多。

不过幸运的是，这个只是测试环境的kafka服务，传输的数据重要程度有限，没有造成什么严重事故。

简要复盘一下原因：

1、由于是测试环境机器，运维没有部署磁盘监控，导致磁盘爆了，无法预知。如果有磁盘监控，本次事故也是可以提前规避掉的。

2、没有限制topic创建权限，导致异常数据量topic耗光磁盘空间，进而导致服务宕机。