In a distributed application system, the interaction between services is a complex web of network communication and data transmission. To process a request in a distributed application system, the internal services of the application system must communicate with each other. If exceptions occur during the process, tasks that are running in the external services may fail to be executed or time out and troubleshooting can be difficult. The tracing analysis feature records the transmission process of requests when services interact with each other in the system. This feature also provides detailed logs and performance data. ApsaraMQ for RocketMQ allows you to integrate trace data that meets the OpenTelemetry specification to Alibaba Cloud tracing analysis services to help you diagnose and troubleshoot exceptions.
What are traces?
The trace data of ApsaraMQ for RocketMQ meets the semantic conventions for messaging spans that are defined in the OpenTelemetry specification. For more information, see Trace Semantic Conventions.
What are messaging spans?
Messaging spans define the topological relationships between different types of spans, including the parent-child and link relationships between send, receive, and process spans. For more information, see Semantic Conventions for Messaging Spans.
The following table describes the span types that are involved in ApsaraMQ for RocketMQ.
span | Description |
send | A message is sent from a producer to a consumer. A span of this type starts when the message starts to be sent and ends when the message is sent, the message fails to be sent, or an exception is thrown. If the message is retried during message sending, multiple spans are recorded. |
receive | The long polling process during which a message is received by a consumer. The lifecycle of a span of this type is consistent with the lifecycle of a long polling. By default, receive spans are disabled. To enable a receive span, you must add the |
process | The process during which a message is processed by the |
The following figure describes the relationships between the preceding types of spans.
If the receive span is disabled, the process span is the child of the send span.
If the receive span is enabled, the process span is the child of the receive span and is linked to the send span.
What are messaging attributes?
Common attributes that are contained in messaging spans are described in the semantic conventions for messaging spans. The following items describe the attributes:
messaging.message.id: the message ID. The ID is the unique identifier of a message.
messaging.destination: the destination to which the message is delivered. In most cases, a destination is a queue or a topic.
messaging.operation: the type of operation that is performed on the message, such as send, receive, and acknowledge.
For information about other attributes, see Apache RocketMQ attributes.
Different messaging products have different behaviors and attributes. The following table describes the unique attributes of ApsaraMQ for RocketMQ.
Attribute | Value type | Description |
messaging.rocketmq.client_group | string | The load balancing group of consumers. |
messaging.rocketmq.client_id | string | The client ID. The ID is the unique identifier of a client. |
messaging.rocketmq.message.delivery_timestamp | int | The scheduled time for sending scheduled messages. |
messaging.rocketmq.message.group | string | The group to which ordered messages belong. |
messaging.rocketmq.message.type | string | The message type. Valid values:
|
messaging.rocketmq.message.tag | string | The tag that is used to filter messages. Consumers can filter messages by tag. This way, consumers can receive only messages that contain the specified tag. |
messaging.rocketmq.message.keys | string[] | The message key. You can configure different keys for different messages. This helps you quickly find messages that you want to manage. |
Limits
Only clients that use the SDK for Java can report trace data to a tracing analysis service. For information about the release notes of the SDK for Java, see Release notes.
ApsaraMQ for RocketMQ traces only production-related data for transactional messages.
ApsaraMQ for RocketMQ traces only the data of messages that are consumed by push consumers. For more information, see Consumer types.
Trace data integration solution provided by ApsaraMQ for RocketMQ
To implement tracing analysis, ApsaraMQ for RocketMQ first reports trace data that meets the OpenTelemetry specification to a tracing analysis server. Then, the server aggregates and displays the trace data.
You can build a tracing analysis server by yourself or use a tracing analysis service provided by Alibaba Cloud as a tracing analysis server. ApsaraMQ for RocketMQ allows you to integrate trace data into Alibaba Cloud Simple Log Service and Application Real-Time Monitoring Service (ARMS). For more information, see Usage notes and What is Tracing Analysis?
Integrate trace data into Simple Log Service
For information about how to integrate the trace data of ApsaraMQ for RocketMQ into Simple Log Service, see Import trace data from Java applications to Simple Log Service by using OpenTelemetry SDK for Java.
Examples:
Tracing of ApsaraMQ for RocketMQ dashboard metrics: In this example, metrics such as the delay of message sending, the success rate of message sending, the success rate of message consumption, and end-to-end latency are displayed. These metrics are based on the trace data of ApsaraMQ for RocketMQ.
Analysis of ApsaraMQ for RocketMQ dashboard metrics: You can perform further analysis on abnormal requests based on message IDs or trace IDs.
Integrate trace data into ARMS
For information about how to integrate the trace data of ApsaraMQ for RocketMQ into ARMS, see Connect OpenTelemetry to Tracing Analysis.