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 conventions

Span Operations

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.

Span Data

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

Data KeyTypeDescriptionConditions
messaging.message.id stringthe 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.count intthe 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.latency floattime delta in seconds between a message being published and when it was received by a consumer (not including processing time on the consumer)

Instrumentation

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>

Distributed Tracing

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.

You can edit this page on GitHub.