EMQX版本:5.8.4,双core节点,配置:4U8G*2,CPU:0.7% 内存:15%
问题简述
调用EMQX的 /api/v5/publish接口时出现2秒超时,QoS为1,但EMQX服务器资源(CPU、内存、网络)正常,且启用的ExHook中 message.publish钩子处理时间仅为3毫秒。希望定位超时原因。
我分析是:这个qos1的publish,分两段来看,client 到 broker, 有可能broker处理超时,回的慢了。再一个阶段就是broker负责给订阅者的至少一次的投递,订阅者回复的ack超时了或者根本就没有回复。
请问有没有对上面这种日志或者监控指标可以作为依据判断问题的原因
你分析的方向对,QoS 1 的 publish API 确实要等订阅者 PUBACK 才返回。
排查思路:
-
开启慢订阅统计(企业版功能)
Dashboard → 问题分析 → 慢订阅,设置时延阈值比如 1000ms,能直接看到哪个订阅者拖慢了响应。
-
日志追踪
Dashboard → 问题分析 → 日志追踪,针对超时的 topic 创建追踪,看具体投递过程。
-
检查订阅者状态
emqx ctl clients show <订阅者clientid>
看 inflight 和 mqueue_len,如果堆积说明订阅者消费慢。
-
Prometheus 指标
- emqx_delivery_dropped - 投递丢弃
- emqx_messages_acked - 确认延迟
如果订阅者确实慢,可以考虑用 QoS 0 的 publish API 或者异步投递。