Queue concepts
A message queue provides lightweight storage for messages, including endpoints that allow applications to connect to it for sending and receiving messages. This storage can be represented as a queue (point-to-point model) or topic (publish-subscribe model).
Prerequisites
OneAgent must run in Full-Stack Monitoring mode to detect queues and topics.
Only in Full-Stack Monitoring mode will Dynatrace create a continuous service flow across producer, listener, and consumer services connected to these queues and topics.
Queues and topics
Message queues are typically implemented with a client-server architecture. Dynatrace OneAgent automatically detects queues and topics when applications send messages to them by instrumenting compatible messaging clients. When queues and topics aren't used by clients, OneAgent cannot access them even though they're available on the server.
Dynatrace creates queue entities for all detected queues and topics. These queue entities are shown on the Queues page, in the Queues and topics table.
| Queue entity | Naming schema |
|---|---|
| Queue | <queue-name> |
| Topic | <topic-name> |
| IBM MQ queue | <queue-manager-name>.<queue-name> |
| IBM MQ topic | <queue-manager-name>.<topic-name> |
Notes
- Dynatrace extensions can detect queues and topics that are available on the message queue server, but they don't result in queue entities in Dynatrace. Hence, they aren't visible in the Queues and topics table.
- Extensions can only add technology-specific metrics to queue entities created by OneAgent.
Services for message queues
Producer and consumer services
- A producer service represents an application that creates messages and sends them to a queue or a topic via a messaging client.
- A consumer service represents an application that connects to this queue or topic via a listener and receives the messages to be processed asynchronously.
- In a JMS-based application (Java message service), there can be also a synchronous consumer service. In this scenario, a client can request the next message from a
MessageConsumersynchronously by using one of its receive methods (for example, the client can poll or wait for the next message).
To provide you with a continuous view of service flows, Dynatrace uses the following identifiers to trace messages across queues and topics
| Identifier | Type |
|---|---|
traceparent and tracestate | HTTP request header |
x-dynatrace | Custom HTTP header |
dtdTraceTagInfo | Custom message property |
| Unique key (generated based on message properties) | - |
Listener services
A listener service, or queue listener service, represents your queue listener or topic listener. It counts how many messages have been dequeued, but it doesn't give you insight into the message processing itself.
Dynatrace automatically detects an event-based message queue handler based on its class name and creates a queue listener service for it. A listener service is always followed by a consumer service, which gives you insight into the message processing details.
If you're just monitoring a queue or topic, and not looking into the message processing, the listener service can exist on its own.
Listener services aren't visible on the analytics pages available from the Queues page, but details are provided on the Service analysis, Service flow, and Distributed traces pages.
Examples
The following is a service flow example with a producer service, queue entity, listener service, and consumer service.
The following is a distributed trace example with a producer service, queue entity, listener service, and consumer service.
