ApsaraMQ for MQTT exports client connect and disconnect events to downstream Alibaba Cloud services through configurable rules. Backend applications consume these events to track connection status, trigger automated workflows, or analyze connectivity patterns.
Status event notifications are asynchronous and do not reflect real-time client status. To query the current status of a client in real time, see Obtain the status of an ApsaraMQ for MQTT client.
How it works
When an ApsaraMQ for MQTT client connects or disconnects, the broker pushes a status notification to a downstream Alibaba Cloud service based on the rule you configured. Backend applications deployed on Elastic Compute Service (ECS) instances subscribe to these notifications to detect client online and offline transitions.

Because this process is asynchronous, a single notification does not indicate whether a client is currently online. To determine actual status, analyze the timeline of event notifications for that client. For details, see Determine client status from events.
Use cases
Status event export triggers backend actions when MQTT clients connect or disconnect. A typical workflow for connection activity analysis:
A client's connection status changes multiple times.
The broker encapsulates each change into a notification based on the configured rule.
The notifications are delivered to an ApsaraMQ for RocketMQ topic.
A backend application consumes the notifications and builds a connection history for the client.
Limits
| Item | Limit | Description |
|---|---|---|
| Rules per instance | 100 | To request a higher limit, join DingTalk group 116015007918 to contact ApsaraMQ for MQTT technical support. |
| Rule deduplication | One rule of each type per internal resource | For example, each group supports one client status notification rule, and each ApsaraMQ for MQTT topic supports one data inbound rule and one data outbound rule. |
| Cross-region rules | Not supported | The data source and data destination must reside in the same region. |
| ApsaraMQ for MQTT instance version | Kernel V3.x.x only | Check the kernel version in the instance list or on the Instance Details page in the ApsaraMQ for MQTT console. |
| ApsaraMQ for RocketMQ instance version | ApsaraMQ for RocketMQ 4.0 only | Applies to data inbound and data outbound rules between ApsaraMQ for MQTT and ApsaraMQ for RocketMQ. |
Resource mappings
Status notifications for all clients in the same ApsaraMQ for MQTT group are forwarded to the same downstream resource.
| ApsaraMQ for MQTT resource | Alibaba Cloud service | Downstream resource | Packet definition |
|---|---|---|---|
| Group | ApsaraMQ for RocketMQ | Topic | Message structure mappings between ApsaraMQ for MQTT and ApsaraMQ for RocketMQ |
Set up status event export
The following steps use ApsaraMQ for RocketMQ as the downstream service.
Prerequisites
Before you begin, make sure that you have:
An ApsaraMQ for MQTT instance with kernel version V3.x.x
An ApsaraMQ for RocketMQ 4.0 instance in the same region
At least one group configured on the ApsaraMQ for MQTT instance
Step 1: Create a client status notification rule
In the ApsaraMQ for MQTT console, create a rule and select the groups whose client status events you want to export. For detailed steps, see Create a rule for client status notifications.
Step 2: Subscribe to status notifications in your backend application
After the rule takes effect, status events are delivered to the configured ApsaraMQ for RocketMQ topic. Subscribe to that topic in your backend application to receive the events. For subscription details, see Subscribe to messages.
Event types
Each status notification is delivered as an ApsaraMQ for RocketMQ message. The event type is specified in the message tag.
Tag format: connect, disconnect, or tcpclean
| Tag | Meaning | Trigger condition |
|---|---|---|
connect | Client connected | The client establishes a connection with the broker. |
disconnect | Client sent a DISCONNECT packet | The client sends a DISCONNECT packet before closing the TCP connection, per the MQTT protocol. If the client SDK does not send this packet, the broker does not generate a disconnect event. |
tcpclean | TCP connection closed | The TCP connection closes, regardless of whether the client sent a DISCONNECT packet. |
To determine whether a client is offline, check for the tcpclean tag, not disconnect. A client that exits unexpectedly may not send a DISCONNECT packet, so the disconnect event may never appear.
Event data format
The message body is a JSON object with the following fields:
| Field | Type | Description |
|---|---|---|
clientId | String | The ApsaraMQ for MQTT client ID. Format: GID_XXX@@@YYYYY. |
time | Long | The timestamp when the event occurred. |
eventType | String | The event type: connect, disconnect, or tcpclean. |
channelId | String | The unique identifier of the TCP connection. |
clientIp | String | The public IP address and port of the MQTT client. |
Example:
clientId: GID_XXX@@@YYYYY
time:1212121212
eventType:connect/disconnect/tcpclean
channelId:2b9b1281046046faafe5e0b458e4XXXX
clientIp:192.168.XX.XX:133XXDetermine client status from events
Because notifications are asynchronous, you cannot determine whether a client is online from a single event. Track the full timeline of events for each clientId and apply the following rules:
Use timestamps for ordering. A larger
timevalue means a more recent event. Compare timestamps only within events that share the sameclientId.Scope offline events by
channelId. EachchannelIdrepresents one TCP connection with exactly oneconnectevent and one close event (tcpclean). Atcpcleanevent invalidates only the connection on the samechannelId-- it does not affect connections on a differentchannelId.Handle transient reconnections. A client may disconnect and reconnect multiple times, producing multiple
channelIdvalues. When you receive atcpcleanevent, verify that itschannelIdmatches the connection you are tracking before marking the client as offline.
Example scenario:
A client connects, disconnects briefly, and reconnects:
| Order | Event | channelId | Client status |
|---|---|---|---|
| 1 | connect | aaa111 | Online (connection aaa111 active) |
| 2 | tcpclean | aaa111 | Offline (connection aaa111 closed) |
| 3 | connect | bbb222 | Online (connection bbb222 active) |
If you receive the tcpclean for aaa111 after the connect for bbb222, the client is still online because bbb222 has no corresponding tcpclean.
Decision logic:
For a given clientId:
1. Maintain a map of channelId -> events.
2. On receiving a "connect" event:
- Store the event under its channelId.
3. On receiving a "tcpclean" event:
- Store the event under its channelId.
- If the channelId has both a "connect" and a "tcpclean" event,
that connection is closed. Remove the channelId from the map.
4. Check if the client is online:
- If any channelId in the map has a "connect" event but no
"tcpclean" event, the client is online.
- If all channelIds have been removed (or have both events),
the client is offline.