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都无效，最后重启机器好了
昵称
0 声望
这家伙太懒，什么都没留下
系统资源耗尽，泄露，到：
/var/log/messages找kernel相关的错误，进行排查。
能具体点么？小白不懂linux.
close_wait是和谁之间的？filebeat、es、kafka集群、kafka connectot restful api之间的调用关系是什么？怎么调用的？
理论上
客户端与kafka集群连接，是长连接，不会关闭。linux系统日志，关键字是
kernel，搜一下当时故障时间点，linux系统是否有什么异常，因为你既然重启了相关的服务，占用的资源应该释放才是。相关时间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
你的答案