Queues Module

The SDK's queue integration is agnostic to the underlying engine used. In most cases, the SDK will instrument existing queue abstractions in certain frameworks or libraries.

Span OPDescription
queue.publishOne or more messages are provided for publishing to an intermediary. If a single message is published, the context of the “Publish” span can be used as the creation context and no “Create” span needs to be created.
queue.createA message is created. “Create” spans always refer to a single message and are used to provide a unique creation context for messages in batch publishing scenarios.
queue.receiveOne or more messages are requested by a consumer. This operation refers to pull-based scenarios, where consumers explicitly call methods of messaging SDKs to receive messages.
queue.processOne or more messages are delivered to or processed by a consumer.
queue.settleOne or more messages are settled.

The following data attributes must be set on both the consumer and the producer spans.

Data KeyTypeDescriptionConditions
messaging.message.idstringthe identifier of the message
messaging.destination.namestringthe destination name where the message is being consumed from, e.g. the queue name or topic
messaging.systemstringthe name of the messaging system, e.g. kafka, aws_sqs

The following data attributes are only to be set if exposed by the instrumented queuing abstraction or retrievable with minimal overhead. When possible, the attributes should be set on both the producer and consumer spans.

Data KeyTypeDescriptionConditions
messaging.message.retry.countintthe retries/attempts processing a message
messaging.message.envelope.sizeintthe size of the message body and metadata in bytes
messaging.message.body.sizeintthe size of the messagebody in bytes
messaging.message.receive.latencyfloattime delta in seconds between a message being published and when it was received by a consumer (not including processing time on the consumer)

Depending on if a synchronous or asynchronous messaging system is used, the consumer span could instead be its own transaction.

Copied
Queue::publish(job)

// in some consumer

Queue::pop()->process()

This should result in the following spans.

Copied
<span op:"queue.publish" description:"job-name" ...>

<span op:"queue.process" description:"job-name" ...>

If applicable, any spans created by the underlying engine instrumentation should be direct children of each queue span.

Copied
<span op:"queue.publish" description:"job" ...>
	<span op:"db.sql.query" description:"insert into jobs" ...></span>
</span>

If applicable, we try to continue a trace from producer to consumer. To do so, we inject both the trace parent (sentry-trace) and baggage into the payload of the message, and pick it up on the consumer.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").