环境信息
- EMQX 版本：4.3.11
- 操作系统及版本：docker
问题描述
如图，大量设备（客户端）断开后重连，设备的技术支持定位说是emqx服务器心跳的问题，请问有什么具体的排查思路吗？谢谢了
你好，单从日志截图上面来看，有一部分是 tcp_closed，这表示 TCP 连接由设备端主动关闭，具体原因还需要从设备端入手排查。还有一部分是 keepalive_timeout，这表示保活超时，也就是设备没有在预期的时间内及时发送心跳报文，同样也需要从设备端入手排查。希望可以帮助到你。
谢谢分析，这个原因可能是因为emq所在服务器资源不足，导致断链。发生批量掉线的时候，一般都在特定时间，比如夜间服务器启动了备份或者杀毒等引起的。请问这种情况在emqx容器中有没有什么方法或者证据证明是因为服务器资源不足导致上述的批量掉线？
另外，由于资源问题导致的批量掉线，同时也导致emqx没有通过webhook发送正确的connected和disconnect成对消息，导致业务侧显示的设备状态没有同步，这时通过定时获取api接口来获得所有设备的在线状态，这种轮询给服务器带来更大的开销，请问emqx有没有这样的配置： 主动定时对客户端的状态上报connected或disconnect状态？
如果有这个功能就能解决状态不同步的问题，或者有更好的方法也请推荐
资源不足应该不会导致 EMQX 主动断开连接的，可能还是需要从你的设备端入手。而且从你提供的截图中看到的设备端主动关闭连接的应该占了大部分，而服务端资源不足不至于导致客户端主动关闭连接。
从wireshark抓包分析的话，fin消息不是设备主动发送的，另外，在每天特定时间内，发生大批量掉网后，很多webhook的disconnect和connect消息都丢失了，这个怎么查看emqx的日志它确实发送了呢？就是出现这种情况后，大量的设备的状态都不同步了
我看到你的日志里面除了 tcp_closed，还有一些 protocol_error, keepalive_timeout 这些原因关闭连接的，这些都属于 EMQX 主动关闭连接的，你看下抓的包是否和确实对应 tcp_closed 的那几个客户端。
消息丢失可能是因为短时间内请求过载导致部分请求超时被放弃了。