kafka 大量 close_wait

一如乞人不需要形象 发表于: 2021-04-26   最后更新时间: 2021-04-26 19:08:28   140 游览

kafka connectot restful api突然某两个机器call不通,timeout,检查发现这两个机器上存在大量close_wait状态的TCP连接(lsof),这些连接有两种类型

  • filebeat送到ELK的连接
  • 本地到kafka集群其他机器的连接,观察pid,这些连接都是来自kafka-server-start.sh

环境:
kafka_2.12-2.5.0.jar, 5个机器

补充:
重启kafka,connector都无效,最后重启机器好了



发表于 15天前

系统资源耗尽,泄露,到:

/var/log/messages

找kernel相关的错误,进行排查。

能具体点么?小白不懂linux.

  1. 重启后只有filebeat的close_wait tcp,多的机器有700多,所以filebeat得看看
  2. 发现问题并重启那天没有对应的message log
  3. 因为重启,其他close_wait的tcp已经没了,所以问题描述第二点是在dev环境的kafka观察到,如果是consumer/producer 没有close, tcp连接不应该描述是本地到kafka集群其他机器的连接吧

close_wait是和谁之间的?
filebeat、es、kafka集群、kafka connectot restful api之间的调用关系是什么?怎么调用的?

理论上客户端与kafka集群连接,是长连接,不会关闭。

linux系统日志,关键字是kernel,搜一下当时故障时间点,linux系统是否有什么异常,因为你既然重启了相关的服务,占用的资源应该释放才是。

  1. close_wait有两种类型,一种是本地跟ELK集群的,一种是本地与kafka集群其他机器的.
  2. 调用关系:
    • 我们用filebeat捕捉connect.log送到ELK.
    • call host:8083拿connector状态,以及启停connector捕获数据送到topic
    • 订阅topic, 消费数据
  3. kernel相关行有三种:
    • systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
    • ntpd[2859]: 0.0.0.0 c01d 0d kern kernel time sync enable
    • 还有一种打了很多行,但没看到有什么Error的

相关时间kernel log只有systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6. 很多行的应该是重启日志

聚焦一下吧:
close_wait是和哪个应用的哪个端口,量大的,先定位到具体的应用。如果是短连接,那close_wait就是正常的了,只是个表现,问题不出在这。
排查各个中间件的内部日志,看看有什么价值的异常日志来帮助定位问题。

close_wait,观察pid,这些连接都是来自kafka-server-start.sh,我再观察观察吧

连接是双向的,连的kafka-server-start.sh,kafka集群是服务,被动的。

怎么看谁连的呀,现在又有一个集群出现这种情况了,保留现场中

netstat -unltpa|grep 9092

根据你的方式,9092 close不多,8083超级多,8083我们每隔30s去Get一下connector的status,没有其他频繁的业务了

目前,我的理解是,因为这个kafka的connector出问题了,8083port 挂了,但monitor不知道,一直call 8083, 所以导致了那么多close_wait

目前,我的理解是,因为这个kafka的connector出问题了,8083port 挂了,但monitor不知道,一直call 8083, 所以导致了那么多close_wait

找不到想要的答案?

我要提问
相关
提问