Monitor the Server by Ignoring the Queue Name
In JMS 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.
To achieve this result, you create a new custom JMS Discovery Rule.
Taking IBM MQ for another 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:
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.