Simple Message Queue (formerly MNS) provides a message trace feature. You can use message traces to trace the complete path of a message. This path includes details such as the time, result, producer, and consumer for each step, such as sending, subscription matching, pushing, and consumption. This feature helps you quickly troubleshoot problems with sending and receiving messages.
Scenarios
Simple Message Queue (formerly MNS) message traces can help you address the following issues:
Check if a message was sent successfully: If you suspect a message was not received, you can use a message trace to confirm whether the message was sent to the queue or topic and whether it was consumed.
Troubleshoot repeated message consumption: If you find that the same message is consumed multiple times, you can use a message trace to view the complete consumption record. This record includes the time, consumer identity, and result for each consumption.
Troubleshoot topic push failures: If a push to an HTTP subscription, email subscription, or other endpoint fails, you can use a message trace to view the detailed push status and the reason for the failure.
Troubleshoot message latency: If you notice high message consumption latency, you can use a message trace to view the time spent at each stage and locate the source of the delay.
Check the status of a scheduled message: You can check whether a scheduled message has reached its preset delivery time.
Query producer and consumer identities: You can view the sender's IP address and AccessKey, and the consumer's IP address. This helps you further investigate issues.
Trace parameter descriptions
Queue message trace
A queue message trace contains three parts: send information, message information, and consumption information.
Send information
Normal send scenario
Parameter | Description |
Message source | The message source is a producer. This means the producer sent the message directly to the queue. |
Method | The API operation type, such as SendMessage or BatchSendMessage. |
Producer IP | The IP address of the client that sent the message. |
AccessKey | The AccessKey used to send the message. |
Send time | The server time when the message arrived at the queue. |
Result | The send result. Displays "Success" or a specific error message. |
Dead-letter scenario
When a message moves from a source queue to a dead-letter queue, a new send trace record is generated.
Parameter | Description |
Message source | Constant: Dead-letter |
Source queue | The name of the original queue |
Source queue message ID | The message ID of the message in the source queue. |
Send time | The time when the message entered the dead-letter queue. |
Result | The send result. Displays "Success" or a specific error message. |
Subscription push scenario
When a topic pushes a message to a queue through a queue subscription, a send trace record is generated.
Parameter | Description |
Message source | Constant: Topic queue subscription |
Topic | The name of the topic that pushed the message. |
Subscription | The name of the subscription that pushed the message. |
Source message ID | The message ID of the message in the topic. |
Send time | The time when the message was pushed to the queue. |
Result | The send result. Displays "Success" or a specific error message. |
Other cloud product scenario
When an event notification pushes a message to a queue through a queue subscription, a send trace record is generated.
Parameter | Description |
Message source | Constant: Other cloud products |
Method | Constant: Notify |
Send time | The time when the message was pushed to the queue. |
Result | The send result. Displays "Success" or a specific error message. |
Message information
Normal message
Parameter | Description |
Message type | Constant: Normal message |
Message ID | The unique identifier of the message. |
Queue | The name of the queue where the message is located. |
Storage duration | The maximum time a message is stored in the queue. This corresponds to the MessageRetentionPeriod property of the queue. |
Visibility timeout period | The default period that a message is invisible after being consumed. This corresponds to the VisibilityTimeout property of the queue. |
Scheduled message
Parameter | Description |
Message type | Constant: Scheduled message |
Message ID | The unique identifier of the message. |
Queue | The name of the queue where the message is located. |
Storage duration | The maximum time a message is stored in the queue. This corresponds to the MessageRetentionPeriod property of the queue. |
Visibility timeout period | The default period that a message is invisible after being consumed. This corresponds to the VisibilityTimeout property of the queue. |
Scheduled Duration | The delay duration of the message in seconds. |
Schedule an end time | The preset time when the message can be consumed. |
Consumption information
The message consumption trace for a queue is grouped by ReceiptHandle. Each ReceiptHandle represents one consumption session for the message.
Parameter | Description |
Current result | The final result of the current consumption session. Results include but are not limited to:
|
Consumer IP | The IP address of the client that received or operated on the message. |
AccessKey | The AccessKey used to operate on the message. |
ReceiptHandle | The message handle. Use it to delete the message or change the message visibility. |
Operation time | The server time when the operation was executed. |
Operation | The API operation that was executed. Operations include the following:
|
A single message can have multiple ReceiptHandles. A new ReceiptHandle is generated each time the ReceiveMessage or BatchReceiveMessage operation is called.
If a consumer deletes a message before its visibility timeout period expires, the result of the consumption session is "Success".
If a consumer retrieves a message but does not delete it, the message becomes available for consumption again after the visibility timeout period expires. This generates a new ReceiptHandle.
If you use an expired ReceiptHandle to operate on a message, a 404 error is returned.
Topic message trace
A topic message trace contains three parts: send information, subscription match information, and push information.
Send information
Normal send scenario
Parameter | Description |
Message source | The message source is a producer. This means the producer sent the message directly to the topic. |
Method | The API operation type, PublishMessage. |
Producer IP | The IP address of the client that sent the message. |
AccessKey | The AccessKey used to send the message. |
Send time | The server time when the message arrived at the topic. |
Result | The send result. Displays "Success" or a specific error message. |
Other cloud product scenario
When an event notification pushes a message to a queue through a queue subscription, a send trace record is generated.
Parameter | Description |
Message source | Constant: Other cloud products |
Method | The API operation type, PublishMessage. |
Send time | The time when the message was pushed to the topic. |
Result | The send result. Displays "Success" or a specific error message. |
Subscription match information
After a topic receives a message, it matches subscriptions based on their filter conditions (FilterTag) and pushes the message to the matching subscriptions.
Parameter | Description |
Message ID | The unique identifier of the message. |
Tag | The tag of the message, used for subscription filtering. |
Subscription name | The name of the matched subscription. |
Subscription type | The endpoint type of the subscription. Types include the following:
|
Push information
Queue subscription
Parameter | Description |
Message ID | The new message ID after the message is pushed to the queue. |
Consumption result | Indicates whether the push was successful. Displays "Success" or a specific error message. |
Push time | The time when the push started. |
Processing time | The time taken for the push, in milliseconds. |
Other subscriptions (HTTP/Email/Alibaba Cloud SMS)
Parameter | Description |
Push result | The status code and result of the push. Codes include the following:
|
Push time | The time when the push started. |
Processing time | The time taken for the push, in milliseconds. |
Limits
Message trace: This feature is disabled by default. You can enable it on the Message Trace page.
Query time range: The start time can be within the last 15 days. Each query can span a maximum of 3 days.
Billing description
For more information, see Message trace fees.
Message trace storage duration
Message trace data is stored for 15 days. Trace data older than 15 days is automatically deleted and cannot be queried.
Query methods
Simple Message Queue (formerly MNS) provides five methods to query message traces. You can choose the appropriate method based on your requirements.
Query method | Scenario | Result |
Query by message ID | Use this method if you know the message ID and need to query the complete trace for that message. | Returns a unique message trace. |
Query by RequestID | Use this method if you know the RequestID of an API call and need to query the messages involved in that request. | Returns the message traces for the messages involved in the request. |
Query by queue name | Use this method to view all message traces for a specific queue within a time period. | Returns the message traces for the queue within the specified time range. |
Query by topic name | Use this method to view all message traces for a specific topic within a time period. | Returns the message traces for the topic within the specified time range. |
Query by subscription name | Use this method to view all message traces pushed by a specific subscription within a time period. | Returns the message traces for messages pushed by the subscription within the specified time range. |
If you know the message ID, use the query by message ID method first to obtain precise results quickly.
To troubleshoot message issues over a period of time, use the query by queue name, topic name, or subscription name method.
Querying by RequestID is useful for troubleshooting API call issues, such as in batch sending or batch consumption scenarios.
Procedure
Query a message trace
Log on to the SMQ console.
In the navigation pane on the left, choose .
In the top navigation bar, select a region.
To enable the message trace feature, click the Off button.
On the Message Trace page, select a query method and enter the query conditions based on your requirements.
Query by message ID: Enter a message ID and click Query.
Query by RequestID: Enter the RequestID of an API call and click Query.
Query by queue name: Select a queue name and a start time. The start time must be within the last 15 days, and the query can span a maximum of 3 days. Then, click Query.
Query by topic name: Select a topic name and a start time. The start time must be within the last 15 days, and the query can span a maximum of 3 days. Then, click Query.
Query by subscription name: Select a topic and subscription name, and a start time. The start time must be within the last 15 days, and the query can span a maximum of 3 days. Then, click Query.
In the query results list, find the target message and click Details in the Operation column.
On the message trace details page, view the complete trace information for the message.
Queue message trace details: Includes send information, message information, and consumption information.
Send information: View the message source, send method, producer IP, AccessKey, arrival time, and send result.
Message information: View the message ID, queue name, storage duration, and visibility timeout period. For a scheduled message, the delay duration and scheduled consumption time are also displayed.
Consumption information: View the message consumption records, grouped by ReceiptHandle. Expand a ReceiptHandle to view all operations for that consumption session, including the time, consumer IP, and result for operations such as receiving, deleting, and changing visibility.
Topic message trace details: Includes send information, subscription match information, and push information.
Send information: View the send method, producer IP, AccessKey, arrival time, and send result.
Subscription match information: View the message ID, tag, matched subscription name, and subscription type.
Push information: View the push result, push time, and other details for each subscription. For a queue subscription, the new message ID after the push is displayed. For HTTP, email, and text message subscriptions, the push status code and processing time are displayed.
(Optional) To view the message trace after a queue subscription pushes a message to a queue, click the Message ID link in the push information. This redirects you to the trace details for that queue message.
FAQ
Q: Why can't I find a message trace?
A: Possible reasons include the following:
The message trace data is older than 15 days and has been deleted.
The query time range is incorrect. Try expanding the time range.
The message ID or RequestID was entered incorrectly. Check the ID and query again.
Q: What does "No acknowledgement" mean in a message trace?
A: "No acknowledgement" means a consumer received a message but did not delete it before the visibility timeout period expired. The message then becomes visible again for consumption. Ensure that your consumer program processes and deletes messages correctly.
Q: Why does a single message have multiple ReceiptHandles?
A: A new ReceiptHandle is generated each time the ReceiveMessage or BatchReceiveMessage API is called to receive a message. If a consumer receives a message but does not delete it, the message becomes visible again after the visibility timeout period expires. Receiving the message again generates a new ReceiptHandle.
Q: Does message tracing affect message sending and receiving performance?
A: No, it does not. Message traces are recorded asynchronously. This process does not affect the performance or reliability of message sending and receiving. Even if trace recording fails, normal message operations are not affected.