AppDynamics Application Intelligence Platform

3.8.x Documentation

PDFs

Videos

Release Notes

This topic covers message queue exit point configuration, including JMS, IBM MQ, and RabbitMQ. To review general information about monitoring databases and remote services (collectively known as backends) and for an overview of backend configuration see Backend Monitoring. For configuration procedures, see Configure Backend Detection (Java).

For a list of supported message-oriented middleware products, see Supported Application Servers and Portals for the App Agent for Java

JMS Message Queue Exit Points

JMS Auto-Discovery and Default Naming

JMS backend activity includes all JMS message send and publish activity. By default, JMS back ends are identified using the logical properties of the JMS server, such as: vendor, destination name, and destination type.

The default configuration uses all three properties of the JMS queue.

From the enabled properties AppDynamics derives a display name, for example, ActiveMQ-OrderQueue.

The Backend Properties are visible on the Remote Services dashboard.

JMS Configurable Properties

The following properties can be configured to refine the identification of JMS backends.

Configurable Properties

Property Used by Default
in Detection and Naming

Destination

Yes

Destination Type

Yes

Vendor

Yes

Changing the Default JMS Automatic Discovery and Naming

Depending on exactly what you need to monitor, there may be times when you want to change the default JMS configuration. In most cases, you can generate the right name and the correct number of backends to monitor by editing the automatic discovery rule. For example, you can disable use of the Vendor property. If you do, then JMS backends with the same destination and destination type are identified as the same backend and the metrics for calls with the same destination and destination type are aggregated into one backend. Changing the default discovery rule can enable you to monitor the key performance indicators (KPIs) that are of most interest to you.

Examples

Monitor the Server by Ignoring the JMS Queue Name

In this example, the application is making calls to a message server that handles several queues. The sample destination names look like this:

  • AccountQ
  • AccountReplyQ
  • AccountRecQ
  • AccountDebitQ

The default automatic discovery rule detects one backend for each unique destination and so the flow map shows one queue backend for each different queue name. In this example, each of the above would show as a separate backend on the application flow map. If you are interested in monitoring the performance of the server and not each queue name, you can modify the configuration to ignore the Destination property and use just the Type and Vendor. This configuration looks similar to the following:

Temporary Queues

In this example an application creates many temporary JMS response queues that are deleted after the message is received. By default, Appdynamics discovers these queues separately and lists each one as a unique remote service. This default behavior probably does not enable effective monitoring. Instead, you can create a custom JMS discovery rule stating that if the destination name contains "TemporaryQueue", list it as "WeblogicTempQueue", or whatever name makes sense in your monitoring environment. In this way, you can monitor the performance that matters. The configuration to accomplish this is shown in the following screen shot:

Session ID in the Queue Name

If your JMS queues use the session ID in the destination, this causes each session to be identified as a separate backend. In this case, you might not be interested in seeing each queue separately, and instead want to aggregate everything for the same host and port to the same backend. You can generate the right name and the correct number of backends to monitor by editing the automatic discovery rule. Doing this enables you to monitor the key performance indicators (KPIs) that are of most interest to you.

IBM Websphere MQ Message Queue Exit Points

IBM Websphere MQ Auto-Discovery and Default Naming

IBM MQ, also known as IBM WebSphere MQ and IBM MQSeries, is IBM's message-oriented middleware similar to JMS. Several additional properties are configurable, such as host and port. This is useful where you have lots of queues and you want to monitor them based on a subset of the properties.

IBM MQ Configurable Properties

You can enable or disable the use of the following properties for IBM MQ exit points.

Configurable Properties

Property Used by Default
in Detection and Naming

Destination

Yes

Destination Type

Yes

Host

Yes

Port

Yes

Major Version

Yes

Vendor

Yes

Example: Monitor the Server by Ignoring the MQ Queue Name

In this example, the application is making calls to a message server that handles several queues. The sample destination names look like this:

  • MQhostwest-US:1521
  • MQhosteast-US:1521
  • MQhostsouth-US:1521

The default automatic discovery rule detects one backend for each unique destination and so the flow map shows one queue backend for each different queue name. In this example, each of the above would show as a separate backend on the application flow map. If you are interested in monitoring the performance of the server and not each queue name, you can create a discovery rule that just uses the Host and Port, as follows:

RabbitMQ Message Queue Exit Points

RabbitMQ Auto-Discovery and Default Naming

RabbitMQ is an open source, commercially supported, messaging middleware that runs on many different operating systems. By default, the App Agent for Java discovers exit points utilizing the RabbitMQ Java API, which is usually shipped as an amqp-client.jar. By default, RabbitMQ backends are identified by Host, Port, Routing Key, and Exchange.  By default, the name would resemble this:

amqp://guest@127.0.0.1:5672/exchange/task_queue

RabbitMQ Configurable Properties

You can enable or disable the use of the following properties for RabbitMQ exit points.

Configurable Properties

Property Used by Default
in Detection and Naming

Host

Yes

Port

Yes

Routing Key

Yes

Exchange

Yes

Changing the Default RabbitMQ Automatic Discovery and Naming

You can change the default RabbitMQ automatic discovery attributes by clicking Edit Automatic Discovery.

A window appears where you can edit the automatic RabbitMQ backend discovery rules.

Example: Monitor the Server by Ignoring the RabbitMQ Queue Name

Configuring properties, such as host and port, is useful where you have lots of queues and want to monitor the health of the server and not the message queue. In this situation, a discovery rule using only host and port might be the most useful strategy as follows:

Learn More

  • No labels

1 Comment

  1. Looks like the screenshot for the TemporaryQueue example is missing the match condition & regex.