Breaking down barriers: IBM MQ tracing across queue managers and queue clusters

Our customers love Dynatrace because of our ability to automatically detect all entities and services within our customers’ monitoring environments, understand all dependencies, trace transactions end to end, and of course, the Davis® AI-driven causation engine that delivers answers based on all monitored data and Dynatrace insights. Dynatrace already offers rich support for tracing your business requests end to end, including all major queue vendors from ActiveMQ, HornetQ, RabbitMQ, Tibco EMS, Software AG’s webMethods Broker and Universal messaging, Azure Service Bus, and IBM MQ.

IBM MQ is of special importance for the IBM stack as it connects the distributed and microservices world with IBM Integration Bus and the IBM Mainframe, all of which are supported by Dynatrace.

IBM MQ poses special challenges

IBM MQ doesn’t allow for easy tracing as the message headers used for this are often disabled. Enabling the headers often isn’t even an option as customers may have thousands of decades-old programs on the mainframe that can’t deal with the headers.

While Dynatrace has already solved IBM end-to-end tracing for its customers, IBM MQ poses a special challenge.

One of the things that needs special consideration is tracing across queue-, queue-manager, and queue-cluster boundaries. For this to work, Dynatrace needs to know which queues are aliases, remote queues, and/or cluster queues. We’ve now added the ability to seamlessly follow messages end to end, even across remote and cluster queues, once Dynatrace is aware of these special features.

Tracing aliases, remote queues, and clusters

First, you must ensure that the IBM MQ tracing feature is enabled. You can find this at Settings > Server-side service monitoring > Deep Monitoring > New OneAgent features.

End-to-end traces are incomplete without the new functionality

If your requests use aliases, remote queues, or cluster queues, your end-to-end traces will be incomplete without the new IBM MQ tracing functionality enabled. This results in two service requests that aren’t connected, one on the sending and one on the receiving side.

After Dynatrace is made aware of aliases, requests are traced end to end

As you can see, the queue names at either end are different. Once Dynatrace has been made aware of the alias, it traces the request end to end:

Smartscape can’t show dependencies without the new feature

Smartscape can’t display dependencies without the new IBM MQ tracing feature. See the example below of a remote queue that Dynatrace is unaware of.

Leveraging the new IBM MQ feature, Smartscape represents the message flow accurately

With the new feature in place, notice the different queue names. Smartscape correctly shows that a message is propagated from the REMOTE_PROCESSING_IN queue to the REMOTE_PROCESSING_OUT queue.

The value of enabling IBM MQ tracing lies in providing a complete, end-to-end trace to the Davis AI, and additionally, in adding more visibility into how messages flow from one queue to the next.

Dynatrace detects aliases, remote queues, and clusters automatically

The IBM MQ plugin automatically discovers aliases, remote queues, and cluster queues for queue manager that it monitors when you enable topology retrieval in your IBM MQ plugin (after you’ve updated to the lastest version) and provide the API endpoint and token.

Using the API instead of the IBM plugin

In addition to the fully automatic discovery of these types of queues by the IBM MQ plugin, you now also have the ability to provide this information to Dynatrace via an API. You can find the IBM MQ tracing API in the Configuration API, and the interface should be self-explanatory:

{
  "name": "name of a queue manager",
  "clusters": [
    "name of a cluster this queue manager is part of",
    "another name of a cluster this queue manager is part of"
  ],
  "aliasQueues": [
    {
      "aliasQueue": "alias queue name",
      "baseQueue": "real queue name",
      "clusterVisibility": [
        "name of a cluster this alias should be visible in",
        "another cluster"
      ]
    }
  ],
  "remoteQueues": [
    {
      "localQueue": "local definition of the remote queue",
      "remoteQueue": "remote queue name",
      "remoteQueueManager": "remote queue manager name",
      "clusterVisibility": [
        "name of a cluster this local definition of the remote queue should be visible in",
        "another cluster"
      ]
    }
  ],
  "clusterQueues": [
    {
      "localQueue": "name of a local queue",
      "clusterVisibility": [
        "name of a cluster this local queue should be visible in",
        "another cluster"
      ]
    }
  ]
}

For tracing of these queues to work in all cases, you need to supply Dynatrace with the respective data.

Tracing messages to IBM IMS on the mainframe

Traces towards IBM IMS on the mainframe also require special attention. For technical reasons, Dynatrace needs to know which queues are direct entries into IMS. The API to provide this information is quite simple; tell Dynatrace the queueName and queueManagerName that represent entry points into IBM IMS.

This API allows you to fully automate your IBM MQ and IBM IMS monitoring within Dynatrace and leverage an end-to-end view, from your most modern microservices to your proven business logic in more traditional systems like the mainframe.