mqtt线上问题
2019-07-25 本文已影响0人
这不是老张么
设备连接mqtt集群被异常断开
以下是查找问题过程和思考过程
- 固件同学提出这个问题后,先在线上mqtt-broker的控制台查看该设备的日志信息,日志显示,设备连接上broker以后,一分钟时间就被断开连接,原因是
closed
,第一想法就是被broker的超时机制给断开了连接。 - 心中还是有一丝疑虑,设备心跳时间设置的是60s,broker是1.5倍心跳时间算超时,然后就开始查找broker配置,看看是不是这个倍数填错了。
- 确认broker超时时间。
emqx.conf
配置的确实是0.75(超时时间=心跳时间 * 0.75 * 2),那是否生效了呢?broker启动后会把所有的配置文件合并到一个大的配置文件中,检查该文件配置的也是正确的,那就奇怪了,但我还是觉得broker配置的问题,于是把线上的所有emqx
相关的配置全都下载到了本地,和正确的配置文件进行比较,但还是没发现什么问题,即使有不一样的地方,也是确定不会出问题的地方。 - 我陷入了深深地思考,现在大致确定和broker的配置没有什么关系,而且从broker日志来看,设备连接上来后,broker没有收到心跳,连接就被断开,但是我的客户端,30s的心跳,却可以收到,进一步判断不是broker的问题。那只有一个可能了,线上和预上线的区别除了集群,配置,就是线上还配置了代理。
- 线上使用
haproxy
来做的tcp
代理,此时心中还有两个怀疑方向,一个是haproxy
超时,或者haproxy
没有转发心跳包,而且更有可能是前者,因为30s的心跳还是可以转发的。 - 于是在本地搭建
haproxy
用于在本地复现问题,成功代理后,确实可以复现,我看线上的haproxy
代理1883
端口的地方没有设置超时时间,所以在运维同学那确认了一下,默认超时时间是60s,这一刻,我已经有百分之九十的把握确定就是这个时间。在本地设置更短的时间10s后,客户端确实在10s的时候就断开了,到此,这个问题可以画上句号了。
总结
从发现问题到解决,花了一天多的时间,其实开始的时候怀疑过代理层的超时时间问题,向运维小姐姐确认了下,是不是有什么超时时间,小姐姐发了一个全局的默认配置截图,我看上面没有60s相关的设置,就转移了注意力。
排查问题,首先还是要清楚整条数据链路,一个一个环节排除。这其中很关键的办法就是找不同,找正确的环境,和错误环境之间的差异,很多次排查问题,这个思路数次把我从困局中解决出来。反思自己的问题,自己不清楚
haproxy
怎么配置,怎么使用,其实也是第一次接触,如果知道监听端口的位置,默认超时时间为60s的话,那首先就会验证这个地方,就不至于走弯路浪费了那么久的时间了。最后,感谢运维小姐姐的积极配合