Upgrade queue monitoring to service message processing
- Latest Dynatrace
- How-to guide
- 7-min read
- Published Aug 18, 2026
In Dynatrace Classic, asynchronous communication is modeled with Queue entities. A Queue entity is created when Dynatrace detects a monitored application interacting with a queue or topic.
In the latest Dynatrace, message processing is measured directly on your services through the dt.service.messaging.* metrics. This guide explains what changes, how each Classic capability maps to its replacement, and how to rebuild the views and alerts you rely on today.
Both models can run side by side. Classic Queue entities continue to work while you validate coverage and rebuild your dashboards and alerts, so you can upgrade at your own pace.
Why the model changed
Queue entities gave you topology and Dynatrace Classic built-in metrics, such as builtin:queue.incoming_requests, attached to the queue entity itself. They showed which services published to a queue and which consumed from it, but they had no relationship to the infrastructure the broker ran on.
Service message processing inverts this. Instead of creating a separate entity to sit between services, Dynatrace measures messaging activity on the services themselves and stores it in Grail as regular metrics. The practical consequences are:
- Message throughput becomes a timeseries you can chart, trend over the full metric retention period, and combine with other metrics in a single query.
- Every data point carries infrastructure context, so you can scope messaging analysis to a Kubernetes cluster or namespace, or to any other primary Grail field, without extra configuration.
- Alerting moves to DQL, so an alert can evaluate any expression over the messaging metrics rather than a single fixed threshold on a chart.
What replaces what
| In Dynatrace Classic | In the latest Dynatrace |
|---|---|
Queues and topics table on the Message queues page |
|
Queue entity, with producer and consumer services attached |
|
Incoming and outgoing message counts on a queue |
|
Producer and consumer services listed on the queue analytics view | Queue nodes and messaging edges in Service Map, or a DQL query for a tabular breakdown |
Set alert from a chart on the queue analytics view | Custom alerts in |
Davis® AI anomaly detection on the Queue entity | No direct equivalent - Davis® AI does not baseline messaging metrics out of the box. Use custom alerts in |
Service flow and distributed traces through a queue | Queue nodes and messaging edges in Service Map and Distributed Tracing |
Concepts that no longer apply
Some Classic concepts have no direct equivalent, because the new model doesn't need them.
- Queue entity
There's no standalone queue entity to open, tag, or place in a management zone. The queue name lives on the metrics as the
messaging.destination.namedimension, and you filter or group by it instead. Cloud-managed queue entities are planned, which will reintroduce a queue entity where the cloud provider can supply one.- Listener services
Classic created a separate listener service for event-based queue handlers, which counted dequeued messages without showing processing detail. The
dt.service.messaging.receive.countanddt.service.messaging.process.countmetrics make this split unnecessary: receive tells you a message arrived, process tells you it was handled, and both are reported on the consuming service.
Before you start
- Confirm that no additional configuration is needed — the
dt.service.messaging.*metrics are collected automatically. - Verify that your queues appear: go to
Services > Explorer > Messaging and check that the queues you want to analyze are listed.
If your applications create temporary queues with generated names, normalize the names before you build dashboards or alerts on messaging.destination.name. Thousands of distinct queue names make aggregations unusable and cause alert configurations to monitor each name separately. See Reduce cardinality of temporary queue names.
Upgrade your queue monitoring
Step 1: Identify what you monitor today
List the Classic queues you actively depend on and define what you want to analyze. The three main use cases for queue analysis are listed below, along with a recommendation for addressing each.
- Analyze queue throughput — rebuild as a dashboard tile (Step 2).
- Analyze services to queue produce/consume interactions — use Service Map or a DQL query (Step 3).
- Alert on message counts or on a Davis problem — use a custom alert (Step 4).
Step 2: Rebuild throughput views
Chart the messaging metrics in a Dashboard or Notebook, splitting by messaging.destination.name to get a per-queue breakdown. For ready-made queries covering throughput and failure rate, see Query examples.
To reproduce the Classic incoming versus outgoing comparison for a single queue, use this query:
timeseries {published = sum(dt.service.messaging.publish.count),received = sum(dt.service.messaging.receive.count),processed = sum(dt.service.messaging.process.count)},by: { messaging.destination.name },nonempty: true, union: true| filter messaging.destination.name == "orderEvents"
A widening gap between received and processed is the new signal for the unbalanced processing that Classic surfaced by comparing incoming to outgoing counts.
Step 3: Rebuild the producer and consumer view
Open Explore service topology with Service Map to see queues as nodes with messaging edges to the services that produce to and consume from them.
When you need a table rather than a graph, for example, to pin per-queue producer and consumer counts to a dashboard, use the DQL query in See which service sends messages to which service.
Step 4: Rebuild your alerts
Recreate each Classic queue alert as a custom alert in 
Anomaly Detection. The two most common Classic alerts map as follows:
- An alert on a growing queue becomes an alert on processing lag, the gap between
dt.service.messaging.receive.countanddt.service.messaging.process.count. - An alert on failed messages becomes an alert on
dt.service.messaging.process.failure_count, usually expressed as a percentage ofdt.service.messaging.process.count.
Both recipes, including the threshold guidance and a caution about queue name cardinality, are in Alerting. For general guidance on configuring custom alerts, see Configure a simple custom alert.
Step 5: Verify before you switch off
Run both models in parallel for at least one full traffic cycle, including a peak period.
- Go to Services > Explorer > Messaging and confirm that the queues you monitored in Classic appear with non-zero throughput.
- Compare message counts:
dt.service.messaging.*figures are typically higher than Classic because they count messages per service independently of trace completeness. This is expected. - Verify that your rebuilt dashboards and alerts fire as expected during a peak period.
- When you're confident in coverage, turn off Classic Queue monitoring for the migrated queues.
Current limitations
- Cloud-managed queue detail is not available yet. Resolving an AWS SQS queue to its cloud resource, and inspecting backlog size, dead-letter statistics, and consumer health, is planned. Use
Clouds for provider-specific queue detail in the meantime. - Service Map is in Early Access. Queue nodes and messaging edges are available in the Explorer (Early Access) view. Metric depth depends on how a node was discovered: Smartscape-based nodes provide full performance insight, while metric-based nodes without a corresponding Smartscape entity show limited data.
- Queue names can be high cardinality. Temporary queues with generated names need normalizing before aggregation is useful.
How does service message processing replace Queue entities?
Previously, Dynatrace modeled asynchronous communication with a dedicated Queue entity, a Smartscape node placed between producer and consumer services. Those entities gave you topology edges and Dynatrace Classic built-in metrics (such as builtin:queue.incoming_requests), but no Grail metrics, and no link to the infrastructure running the broker.
Service message processing replaces that model with metrics attached directly to your services:
| Aspect | Queue entities | Service message processing |
|---|---|---|
Topology | Edges only. Producer and consumer services linked through a Queue node | Queue nodes and messaging edges in Service Map, plus full queryability through the |
Metrics | Dynatrace Classic built-in metrics only (such as | Four dedicated metrics stored in Grail, queryable with DQL and chartable over the full metric retention period |
Infrastructure context | None. Queue entities were standalone and carried no relationship to hosts, clusters, or cloud accounts | Primary Grail fields are present as dimensions on every data point |
Alerting | Threshold alerts configured per chart | Custom alerts in |
The practical difference is that message processing is now measurable rather than only visible. You can trend throughput over months, alert on failure rate per queue, and correlate messaging behavior with the infrastructure the services run on. Trending throughput over months, alerting on failure rate per queue, and correlating messaging behavior with infrastructure were not possible with Queue entities.
Why do message counts differ from what Queue entities reported?
Queue entity message counts were derived from distributed traces, so they only counted messages that appeared in a complete, instrumented trace. If a producer or consumer was not monitored, the reported count was lower than the actual number of messages.
The dt.service.messaging.* metrics are collected per service independently of trace completeness. Counts are therefore often higher, and more accurate, than the equivalent Queue entity figures, particularly in environments where not every service is instrumented.
Next steps
- Monitor service message processing for the full metrics reference, dimensions, and query examples.
- Explore service topology with Service Map for navigating service topology, including queue nodes.
- Explore the service entity in Smartscape on Grail for how services and their dependencies are modeled in Smartscape.
Services