记一次metricbeat与kafka集群连接失败问题处理_metricbeat 报错 failed to fetch key info for key in

记一次metricbeat与kafka集群连接失败问题处理

问题描述

原本配了90台服务器通过metricbeat上传监控数据到kafka，一开始有45台左右上传数据成功，某一时刻突然掉到了14台。

问题排查

• 在kafka新建名为test的topic，选择一台metricbeat服务器上传数据到test，test一直未收到数据；
• 修改metricbeat配置，使之直接传数据到logstash，结果同样收不到数据；
• 使用netstat命令查看kafka侧已建立的tcp连接，并注意状态信息，未发现metricbeat侧的连接；
• 查看已掉线metricbeat日志发现在正常采集日志，重启服务后有日志显示连接已建立成功，使用tcpdump抓包，发现本地不断发出SYN flags[S]包去连接kafka侧,但是一直未收到kafka侧的回包；
• 在kafka侧未发现收到数据，在kafka侧使用tcpdump抓包，发现metricbeat车发来大量SYN包flags[S]，kafka侧发出SYN/ACK包flags[S.]。

问题分析

logstash也收不到数据，说明大概率不是kafka的问题，抓包后观察特征，发现kafka侧可以收到metricbeat侧的数据包，但是metricbeat侧无法收到kafka侧的数据包。由此怀疑是metricbeat侧的防火墙挡住了kafka侧的数据包。

问题解决

配置metricbeat侧的防火墙，放通kafka侧的特定端口可以访问metricbeat侧的特定ip段的任意端口，所有服务器数据上传成功！

遗留问题

• metricbeat与kafka连接，发送第一个请求连接的包之后并没有收到kafka的回包，但是依然显示连接成功，怀疑这是metricbeat的bug，metricbeat版本为7.9.3；
• 虽然metricbeat侧未做放通kafka侧的防火墙策略，但是前期依然有些服务器可以成功上传数据，怀疑是防火墙做过某些操作，或者是其他问题。

心得

• 根据经验，如果这种集群系统出现连接问题，多半是网络方面的配置问题，可以采用抓包的方式来排查问题点。
• tcpdump是一个很好用命令行抓包工具，特别要注意flags标志位的状态，标识为的状态有S(SYN)|F(FIN)|P(PUSH)|R(RST)|E(ECN-Echo)|W(ECN-CWT)，分别为【建立连接请求｜断开连接请求｜发送数据｜复位｜通知网络堵塞｜确认接受到网络堵塞通知】，但是要注意flags[S.]表示的是收到连接请求后回复的确认包，此时后面应该会看到ACK字段S后面的.应该就代表ACK。
• tcpdump命令：tcpdump -i (网卡) host (对端ip)

tcpdump详解