Using MQ 9.0 system topics for resource monitoring and MQ Console for showing charts. IBM Techdoc:

Transcription

1 Page 1 of 22 Using MQ 9.0 system topics for resource monitoring and MQ Console for showing charts IBM Techdoc: Date last updated: 07-Sep-2017 Angel Rivera rivera@us.ibm.com IBM MQ Support +++ Objective +++ The objective of this techdoc is to show how to use the new feature introduced in MQ 9.0 of System Topics, which can be used for resource monitoring. It also shows how to use the new feature in MQ to see Charts in the MQ Console (via a web browser) The chapters are: Chapter 1: Baseline: using default interval rate of 10 seconds Chapter 2: Examples of using the sample amqsrua Scenario 1: You want to interact with the tool and select the desired system topic on the fly Scenario 2: You do not want to interact with the tool and instead, you specify the desired class/type from the command line Chapter 3: Tree of the Classes and Types of the resources to be monitored Chapter 4: Example of altering the interval from 10 seconds to 20 seconds Chapter 5: Example of using MQ Console to add monitoring Charts (via a web browser) Appendix: References to the online manual and blog articles from MQ developers ++ Configuration - Queue manager in Linux, using MQ , name QM90 in host named "mosquito", port MQ Explorer in Windows. 1

2 Page 2 of Chapter 1: Baseline: using default interval rate of 10 seconds By default, the queue manager behaves like if having the following stanza in the qm.ini. NOTE: You do NOT have to specify this stanza in order to get the default behavior! I am just showing the stanza because it will be explicitly used in later chapters. File: qm.ini for the queue manager TuningParameters: MonitorPublishHeartBeat=10 To test the publishing of messages for the system topics, 2 local queues will be created that will contain the published messages for 2 subscribers of system topics - Two local queues to received the messages: QSUB1 => to be used with SUB1 (for MetaData) QSUB2 => to be used with SUB2 (CPUQMgrSummary) - Two subscriptions: SUB1 topic $SYS/MQ/INFO/QMGR/QM90/Monitor/METADATA/CPU/QMgrSummary => Which receives the messages in the provided queue QSUB1 SUB2 topic $SYS/MQ/INFO/QMGR/QM90/Monitor/CPU/QMgrSummary => Which receives the messages in the provided queue QSUB2 The definitions are shown bellow: runmqsc QM90 define qlocal(qsub1) define qlocal(qsub2) define sub(sub1) dest(qsub1) destclas(provided) + topicstr('$sys/mq/info/qmgr/qm90/monitor/metadata/cpu/qmgrsummary') define sub(sub2) dest(qsub2) destclas(provided) + topicstr('$sys/mq/info/qmgr/qm90/monitor/cpu/qmgrsummary') end 2

3 Page 3 of 22 This is the screen capture from MQ Explorer showing the subscriptions:... and the queues: 3

4 Page 4 of 22 The queue QSUB1 has only 1 message and this message contains the metadata: One way to see all the contents of the message for queue QSUB1 is to use the sample amqsbcg: mqm@mosquito: /var/mqm/qmgrs/qm90 $ amqsbcg QSUB1 QM90... **** Message **** length of 580 bytes : '...$...' : '...' : DF '...D...' : D ' QM90 ' : ' ' : ' ' : '...' : 'G...' : 'H...' : 4B 'K...' A0: 511F 'Q...' B0: 'I...' C0: 4A C 'J...'...L...' D0: 9B0A 0000 B ' User' E0: D D ' CPU time - perc' F0: 656E D 'entage estimate ' : 666F D61 6E 'for queue manage' : F 0000 'r...q...' : '...I...' : A '...J...' : C B0A 0000 '.'...L...' : B D 2043 ' System C' : D D E 'PU time - percen' : D F 'tage estimate fo' : D61 6E 'r queue manager.' : F '...Q...' A0: '...I...' B0: A '...J...' C0: B0A 0000 B '...@...' D0: 2C D20 746F C ',...RAM total by' E0: D D 'tes - estimate f' F0: 6F D 616E 'or queue manager' : E B '...D...' : 2E F4D 512F 494E 464F '...$SYS/MQ/INFO' : 2F51 4D47 522F 514D F4D 6F6E 6974 '/QMGR/QM90/Monit' : 6F72 2F F51 4D D 6D61 'or/cpu/qmgrsumma' : 'ry.. ' 4

5 Page 5 of 22 In contrast to QSUB1 which had only 1 message, the queue QSUB2 has many messages. These messages are published by the queue manager for the System Topic in SUB2. In this case 88 messages: 5

6 Page 6 of 22 Then you will see that the messages are published at 10 seconds interval, which is the default. Message 1, Put date/time 5:27:04 AM Message 2, Put date/time 5:27:14 AM Message 3, Put date/time 5:27:24 AM and so on... 6

7 Page 7 of Using MQ Explorer to show the status of the topics The following is for the METADATA topic: $SYS/MQ/INFO/QMGR/QM90/Monitor/METADATA/CPU/QMgrSummary It shows that there is 1 active subscriber, and 0 active publisher. Question: Why is there a 0 for the Pub count (Publisher)? Answer: Because the publishing (the queue manager itself) just publishes a single message into the METADATA topic, and that is all. Because there are no more messages to be published for the metadata, therefore there is no active publisher anymore for this topic. 7

8 Page 8 of 22 To show the Topic Status, for the desired queue manager, select: Topics > Status... Then select the topic: $SYS/MQ/INFO/QMGR/QM90/Monitor/CPU/QMgrSummary It shows that there is 1 active subscriber, and 1 active publisher. 8

9 Page 9 of Chapter 2: Examples of using the sample amqsrua + Scenario 1: You want to interact with the tool and select the desired system topic on the fly For example, you want to select first: CPU then: QMgrSummary mqm@mosquito: /var/mqm/qmgrs/qm90 $ amqsrua -n 10 -m QM90 CPU : Platform central processing units DISK : Platform persistent data stores STATMQI : API usage statistics STATQ : API per-queue usage statistics Enter Class selection ==> CPU SystemSummary : CPU performance - platform wide QMgrSummary : CPU performance - running queue manager Enter Type selection ==> QMgrSummary Publication received PutDate: PutTime: Interval:8.528 seconds User CPU time - percentage estimate for queue manager 0.02% System CPU time - percentage estimate for queue manager 0.00% RAM total bytes - estimate for queue manager 180MB 9

10 Page 10 of 22 + Scenario 2: You do not want to interact with the tool and instead, you specify the desired class/type from the command line The following options are added to the command specified in Scenario 1. This will avoid the interaction with the tool to manually narrow down the topic of monitor. -c CPU -t QMgrSummary mqm@mosquito: /var/mqm/qmgrs/qm90 $ amqsrua -n 10 -m QM90 -c CPU -t QMgrSummary Publication received PutDate: PutTime: Interval:8.023 seconds User CPU time - percentage estimate for queue manager 0.00% System CPU time - percentage estimate for queue manager 0.03% RAM total bytes - estimate for queue manager 180MB Publication received PutDate: PutTime: Interval: seconds User CPU time - percentage estimate for queue manager 0.00% System CPU time - percentage estimate for queue manager 0.00% RAM total bytes - estimate for queue manager 180MB 10

11 Page 11 of Chapter 3: Tree of the Classes and Types of the resources to be monitored See the following web page from the online manual for the tree of the classes (CPU, DISK, etc) and the corresponding Types within each class. Also, see an example of running the amqsrua command, by selecting a class and then selecting a type. doc/mo00013_.htm WebSphere MQ > WebSphere MQ > IBM MQ > Monitoring and performance > Monitoring your IBM MQ network > System topics for monitoring and activity trace > Monitoring system resource usage by using the amqsrua command + begin excerpt The amqsrua command reports metadata that is published by queue managers. This data can include information about the CPU, memory, and disk usage. You can also see data equivalent to the STATMQI PCF statistics data. The data is published every 10 seconds and is reported while the command runs. + end excerpt ++ Classes and Types The following is the tree structure of the Classes (CPU, DISK, etc) and the Types within each Class. Also, an example of the output for each of the types is shown, in that way, you will see the specific data that is being displayed by the amqsrua command. CPU : Platform central processing units SystemSummary : CPU performance - platform wide Example output: Publication received PutDate: PutTime: Interval: seconds User CPU time percentage 13.03% QMgrSummary : CPU performance - running queue manager Example output: Publication received PutDate: PutTime: Interval: seconds User CPU time - percentage estimate for queue manager 0.00% System CPU time - percentage estimate for queue manager 0.00% RAM total bytes - estimate for queue manager 148MB 11

12 Page 12 of 22 DISK : Platform persistent data stores SystemSummary : Disk usage - platform wide Example output: Publication received PutDate: PutTime: Interval: seconds MQ errors file system - bytes in use MB MQ errors file system - free space 3.26% MQ FDC file count 141 MQ trace file system - bytes in use MB MQ trace file system - free space 3.26% QMgrSummary : Disk usage - running queue managers Example output: Publication received PutDate: PutTime: Interval: seconds Queue Manager file system - bytes in use MB Queue Manager file system - free space 3.26% Log : Disk usage - queue manager recovery log Example output: Publication received PutDate: PutTime: Interval: seconds Log - bytes in use Log - bytes max Log - physical bytes written 0 Log - logical bytes written 0 Log - write latency usec STATMQI : API usage statistics CONNDISC : MQCONN and MQDISC OPENCLOSE : MQOPEN and MQCLOSE INQSET : MQINQ and MQSET PUT : MQPUT GET : MQGET SYNCPOINT : Commit and rollback SUBSCRIBE : Subscribe PUBLISH : Publish. Example output for CONNDISC Publication received PutDate: PutTime: Interval:4 minutes, seconds MQCONN/MQCONNX count 23 Failed MQCONN/MQCONNX count 0 Concurrent connections - high water mark 24 MQDISC count 8 12

13 Page 13 of 22 STATQ : API per-queue usage statistics OPENCLOSE : MQOPEN and MQCLOSE INQSET : MQINQ and MQSET PUT : MQPUT and MQPUT1 GET : MQGET Example for OPENCLOSE An object name is required for Class(STATQ) Type(OPENCLOSE) Enter object name 13

14 Page 14 of Chapter 4: Example of altering the interval from 10 seconds to 20 seconds + Test 1: Increasing MonitorPublishHeartBeat from the default 10 seconds to 20. I stopped the queue manager and then added the following to the qm.ini file: TuningParameters: MonitorPublishHeartBeat=20 Then restarted the queue manager. The local queue QSUB1 had only 1 message, as expected because it is the metadata. No new messages are added. This is the correct behavior. I monitored the local queue QSUB2 and see that new messages were published every 20 seconds. I waited to see that 15 messages were generated. I also used amqsrua and see that new messages were published also every 20 seconds. So far, so good. I was able to confirm that increasing the interval from 10 to 20 worked fine and messages were consistently generated every 20 seconds. + Test 2: Increasing MonitorPublishHeartBeat to 60 I performed a refinement of Test 1, by increasing the value to 60 seconds I stopped the queue manager and then altered the following to the qm.ini file: TuningParameters: MonitorPublishHeartBeat=60 Then restarted the queue manager. Immediately upon restarting the queue manager, I checked the queues: QSUB1 (the metadata), had only 1 message, as expected. No new messages will be added and this is ok. QSUB2, it started showing 1 message. I waited a couple of minutes and refreshed MQ Explorer. It showed that there are now 3 messages, one record added every 60 seconds.. 14

15 Page 15 of 22 The sample amqsrua fails to work properly at this moment, and this is already described in one of blog articles, because the sample uses an MQGET with a waiting get limit of 30 seconds. Thus, because a new message at this point is added every 60 seconds, then the MQGET terminates at 30 seconds, as expected. This means that only 1 message is shown. I was able to confirm that increasing the interval to 60 worked fine and messages were consistently generated every 20 seconds 15

16 Page 16 of Chapter 5: Example of using MQ Console to add monitoring Charts (via a web browser) MQ introduced a new feature: the MQ Console that is a web browser interface to administer MQ queue managers. This chapter does not cover how to star the MQ Console and how to use a web browser to access the MQ Console functionality. The purpose of this chapter is to show how you can customize the MQ Console to add "widgets" for Charts that monitor automatically the desired resources! For more information on the MQ Console see: doc/q127580_.htm IBM MQ > IBM MQ 9.0.x > IBM MQ Administering > Administration using the IBM MQ Console > Getting started with the IBM MQ Console Assuming that you have started the MQ console and you have a web browser pointing to it. Click on "Add Widget" Then click on "Chart" (Monitor your MQ platform) 16

17 Page 17 of 22 You will see a blank widget. Click on the icon for Settings: You will see a "Chart" that you can configure. The default is to monitor CPU usage. (You can customize what you want to monitor by modifying "Resources to monitor") In this case, the following was configured: Widget title: My Monitoring for QM901 Queue managers to monitor: QM901 Then click on "Save" (at the bottom right corner) 17

18 Page 18 of 22 You will see the values of the chart being updated frequently: Some moments later the chart will be automatically updated... 18

19 Page 19 of 22 Let's add another queue manager. Now the combined chart looks like this: 19

20 Page 20 of 22 Let's add another widget, this time for Disk usage: Now the charts look like this (within the same MQ console): 20

21 Page 21 of Appendix: References doc/mo00040_.htm WebSphere MQ > WebSphere MQ > IBM MQ > Monitoring and performance > Monitoring your IBM MQ network > System topics for monitoring and activity trace + begin excerpt System topics in queue manager topic trees are used for resource monitoring and for application activity trace. Each queue manager s topic tree contains the $SYS/MQ branch. The queue manager publishes to topic strings in this branch. An authorized user can subscribe to these topic strings to receive information on the queue manager and the activity on it. These system topics are used for application activity trace. For more information, see Topic Trees. The root of the $SYS/MQ branch is represented by the SYSTEM.ADMIN.TOPIC topic object. The $SYS/MQ branch of the topic tree is isolated from the rest of the topic tree in the following ways:... + end excerpt c/mo00014_.htm WebSphere MQ > WebSphere MQ > IBM MQ > Monitoring and performance > Monitoring your IBM MQ network > System topics for monitoring and activity trace > Developing your own resource monitoring program. + begin excerpt The topic tree for the meta data has the following structure: $SYS/MQ/INFO/QM/QMGR-NAME/Monitor/class[/instance]/type] + end excerpt Note: In the example shown in this techdoc for amqsrua, the specific topics that are monitored are: $SYS/MQ/INFO/QMGR/QM90/Monitor/METADATA/CPU/QMgrSummary $SYS/MQ/INFO/QMGR/QM90/Monitor/CPU/QMgrSummary 21

22 Page 22 of 22 _published_to_the_system_topic_in_mq_v9?lang=en Statistics published to the system topic in MQ v9 MarkWhitlock June The following article has additional explanation (and caveats) about using MonitorPublishHeartBeat _Publish_and_be_damned?lang=en MQ Statistics. Practising self-control +++ end