{"id":380,"date":"2017-11-22T19:12:42","date_gmt":"2017-11-22T19:12:42","guid":{"rendered":"https:\/\/marketaylor.synology.me\/?p=380"},"modified":"2019-11-19T19:41:12","modified_gmt":"2019-11-19T19:41:12","slug":"adding-resource-statistics-to-your-applications","status":"publish","type":"post","link":"https:\/\/marketaylor.synology.me\/?p=380","title":{"rendered":"Adding resource statistics to your applications"},"content":{"rendered":"

MQ V9 added resource monitoring statistics that you can subscribe to. In this post I\u2019m going to show how you can generate similar statistics from your own applications using the same model. For example, you may want to track how many successful and how many failed messages are being processed.<\/p>\n

<\/p>\n

Introduction to resource statistics<\/h2>\n

Queue managers on the Distributed platforms publish many statistics about themselves and the systems they are running on. This started with MQ V8 on the Appliance, and was extended to the other platforms in V9. The fundamental concept is that a monitoring program retrieves metadata that describes the statistics from the queue manager and then subscribes to topics representing the real data. For more information about this approach, see Mark Whitlock\u2019s post here<\/a>.<\/p>\n

Mark Bluemel then wrote an article about decoding the statistics that you can read here<\/a>.<\/p>\n

But the idea of the metadata can be extended to other components too. It does not have to apply only to queue manager internal data. I used the design to add statistics to a new component of MQ, the MQ Bridge to Salesforce<\/a> that was first shipped in MQ V9.0.2. I\u2019ve also received several questions about how these statistics work, and there seemed to be a positive reaction from an MQTC<\/a> audience when I proposed writing up the approach.<\/p>\n

So this post describes and links to some code that you can copy and extend for generating arbitrary application-specific statistics.<\/p>\n

The model<\/h2>\n

The design for these statistics involves a three-level classification. There are Classes<\/strong>, Types<\/strong>, and Elements<\/strong>. It is the Element that holds the actual values that can be displayed. An element may be further qualified with a name \u2013 in the queue manager statistics, this is where you see the Queue Name being used. Both the metadata and the real values are contained in PCF messages.<\/p>\n

When you want to add monitoring of your own applications, it is this model that you need to design first. The three tiers are a given; that cannot be changed. For some of the values I needed to generate, a design involving just two levels felt more appropriate but I had to introduce what was essentially a \u201cpadding\u201d level in the middle. That padding used the same name and description for the Type layer as for the Class, which seemed redundant but it was the only way to follow the model.<\/p>\n

The sample program<\/h2>\n

I\u2019ve posted a short program that creates and describes some statistics as a gist download<\/a> on Github. The statistics produced by this program are very simple \u2013 there are counts of \u201csystem level\u201d values, and counts for some specific named objects \u2013 but it should demonstrate how it can be extended for more realistic statistics. The program includes comments to describe what is going on at each step. It uses JMS as the core messaging API, but other APIs and languages could be used. Java does make it easy to work with PCF messages, though you can see some special considerations when writing those messages via JMS to ensure correct formatting.<\/p>\n

After connecting to the queue manager, the program builds metadata describing the classes, types and individual elements, and publishes these as retained<\/strong> publications. That allows monitoring programs to start up at any time and still be able to get the metadata. The metadata only needs to be published once, in this case as the program starts up. You can see the construction of the tree and the MQ messages that describe it in the publishMetaData()<\/em> method. The program then continues to loop, publishing random numbers for each element.<\/p>\n

How did I design this<\/h2>\n

There is not a huge amount of formal documentation on these resource statistics. One reason for that is the flexibility and potential for change given by the metadata approach. The best information on decoding the events is from the amqsrua sample program. I used both that program\u2019s source code and the executable to validate what was going on. I also used the amqsevt program a lot, subscribing to the various topics and seeing both how PCF components were built and that my generated messages matched the queue manager\u2019s construction.<\/p>\n

Notes<\/h2>\n

There are several things to note here:<\/p>\n