| Author |
Message
|
| Boomn4x4 |
 Posted: Fri Jun 22, 2012 4:28 am Post subject: Some key things to be monitoring |
 |
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
I've been working on putting together a demonstration for a solution to MQ monitoring using Xymon (fka Hobbit fka Big Brother).
I'd like to get a decent number of monitors in place to demonstrate, but don't necessarily want to go overboard. So far I have alerts in place to demonstrate:
- Queue depth of messages in the DLQ
- MSGAGE of messages in the system.cluster.transmit.queue
- Cluster Sender / Receiver channel status
- Listener status
Can anyone suggest some other good monitors that I can demonstrate?
[/list] |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jun 22, 2012 4:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Search google for competitive products to see what they monitor. You can also read the WMQ Performance manual.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 22, 2012 5:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you trying to monitor the health of the queue manager?
Or the health of the applications using the queue manager?
Typically, you need to do both. |
|
| Back to top |
|
|
| Boomn4x4 |
| Posted: Fri Jun 22, 2012 5:21 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| mqjeff wrote: |
Are you trying to monitor the health of the queue manager?
Or the health of the applications using the queue manager?
Typically, you need to do both. |
Yes.
But my question isn't geared towards the application side as I've got written into my MQ API calls to test the RC and send alert messages based on that. For demonstration purposes... I'm happy there.
Essentially, I'm just asking about the health of the queue manager. And I certainly don't need an all inclusive list. Just a few relevant monitors that I can demo to my managers. I've been reading through all the documentation and there are a TON of things I ~can~ monitor... I'm just looking for some advice as to what would be some good basic monitors to have in place that I may not be thinking of. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 22, 2012 5:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Boomn4x4 wrote: |
| mqjeff wrote: |
Are you trying to monitor the health of the queue manager?
Or the health of the applications using the queue manager?
Typically, you need to do both. |
Yes.
But my question isn't geared towards the application side as I've got written into my MQ API calls to test the RC and send alert messages based on that. For demonstration purposes... I'm happy there. |
Even for demo purposes, that's not necessarily sufficient.
If the app entirely crashes, it's not going to be sending any alerts that it's failed to read messages.
So the first time you'll know that the app is dead is when the DLQ starts piling up because the queue the app reads from is now full. And that could, in production, be days later. |
|
| Back to top |
|
|
| Boomn4x4 |
| Posted: Fri Jun 22, 2012 6:07 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| mqjeff wrote: |
So the first time you'll know that the app is dead is when the DLQ starts piling up because the queue the app reads from is now full. And that could, in production, be days later. |
I should have specified. The app that I am responsible for doesn't read, only puts to a clustered queue. Broker on the other end is pulling messages off. Tivoli will be monitoring this system, this is outside of my scope. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 22, 2012 6:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Why aren't you using Tivoli to monitor this queue manager as well, then? |
|
| Back to top |
|
|
| Boomn4x4 |
| Posted: Fri Jun 22, 2012 6:40 am Post subject: |
|
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
| mqjeff wrote: |
| Why aren't you using Tivoli to monitor this queue manager as well, then? |
Because my organization didn't purchase licenses for the 5,000 systems it would need to be on. They only purchased licenses for the HQ systems. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 22, 2012 6:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Boomn4x4 wrote: |
| mqjeff wrote: |
| Why aren't you using Tivoli to monitor this queue manager as well, then? |
Because my organization didn't purchase licenses for the 5,000 systems it would need to be on. They only purchased licenses for the HQ systems. |
ok...
I'd write up an estimate of the time it will take you to implement *and maintain* your own monitoring, and compare that to the cost of the tivoli client for the machine.
Then I'd submit that along with your preliminary design.
Otherwise, it seems like you have an okay set of things to monitor. You could consider monitoring the svrconns as well as the listener - because if the listener dies it doesn't affect active channels. Likewise you might want to check on open output counts. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 22, 2012 7:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Add to your list o/s resources that affect performance of WMQ, and WMQ apps. RAM, CPU utilization. Poorly provisioned Disk I/O rates/delays can adversely affect app performance, including perf of your perf monitor.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 22, 2012 1:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
QM Status
any FDC files
Specific AMQ* entries in the AMQERR**.log files
Cluster command queue depth and IPROCS
QM command queue depth and IPROCS
Disk space
etc
etc
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
