| Author |
Message
|
| sandiksk |
 Posted: Thu Feb 07, 2008 7:47 am Post subject: ITM v6 with Omegamon Xe |
 |
|
Centurion
Joined: 08 Jun 2005
Posts: 133
|
Hey guys,
I was asked by my company to list all the things that Omegamon can monitor, I ones i can thik about are
I have a windows server with ITM 6 and Omegamon installed on it...
Here's the list i can think of
Channel (Stopped, retry)
Queue(High, low, Full)
Listener
Channel initiator
Queue Manager Status
Queue Statistics( Like Avg message time, Oldest mesasge time, Total messages..)
Dead Letter Queue
Command Server
Message statistics
Application Accounting(about MQi calls.)
Can you Guys thing of anything i missed or that i got wrong in the list above
And if we have WMQ configuration agent installed we can change the attributes of the MQ objects Right?
How do i know if the configuration is installed.
Any suggestion would be appreciated.
Thanks in advance |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Feb 07, 2008 7:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
What does the Omegemon documentation say it can monitor?
This is a slightly different question to what should it monitor (which has been the subject of discussion in here).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sandiksk |
| Posted: Thu Feb 07, 2008 8:10 am Post subject: |
|
|
Centurion
Joined: 08 Jun 2005
Posts: 133
|
Vitor,
My post mostly summarizes the things it can do(which i read from documentation), i just wanted to make sure i did not miss some things and btw my company also asked me to list the most imp things that should be taken care for now in those list.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 07, 2008 8:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sandiksk wrote: |
| my company also asked me to list the most imp things that should be taken care for now in those list.. |
I commend to your attention the previous posts on monitoring WMQ, which will be of value in assembling your list.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sandiksk |
| Posted: Thu Feb 07, 2008 8:33 am Post subject: |
|
|
Centurion
Joined: 08 Jun 2005
Posts: 133
|
| Don't know if i am searching wrong but i could'nt find a post that exaclty lsit the thigns that should be monitored..Little help would be appreciated. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 07, 2008 9:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| sandiksk wrote: |
| Don't know if i am searching wrong but i could'nt find a post that exaclty lsit the thigns that should be monitored..Little help would be appreciated. |
Monitor everything.
Or nothing.
As your requirements demand.
Isn't it your job to match your requirements to the implementation details?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Fri Feb 08, 2008 10:30 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
To expand a bit on the above posts:
You've got a good list of things that can be monitored. To know which ones should be monitored, you must look at how MQ is being used.
For example, I do not monitor all sender and receiver channels. I monitor only those that service applications; I do not monitor channels that are used exclusively by WMB to communicate with the configuration manager.
Another example, I do not monitor dequeue rates on the xmitqs because I expect certain downtime on the receiving end. The xmitqs are sized to accommodate this downtime, and alerts are based on the depth of the queue only.
Sometimes I create alerts that are fired directly to application teams, such as an alert when IPPROCS are a certain value.
IMHO, queue depth alerts should not be applied in a blanket fashion, either. Some queues need thresholds very low and some very high, depending on the use of the queue.
It's a common error, I think, to apply identical monitoring to all MQ objects in an environment. That is a waste of human and machine resources, IMHO, and make alerts fairly useless.
My 2 cents!
Shirley |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 08, 2008 1:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| SAFraser wrote: |
I do not monitor channels that are used exclusively by WMB to communicate with the configuration manager.
|
I would change that if I were you. One morning at 2 AM my deploy wouldn't work. The clock is ticking to get it done to sync up with some mainframe code changes. Finally we saw that the channel between the config manager and the broker was having issues, and my deploy messages were twiddling their thumbs in the config manager's XMITQ.
We started monitoring that link the next day on all our config managers!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| SAFraser |
| Posted: Fri Feb 08, 2008 1:56 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
Peter,
What a perfect example of the point I was making!
If I were doing 2:00 AM deployments in a big environment, you can bet I'd be monitoring those channels.
But in my current environment, WMB deployments are uncommon because the code for this project is in maintenance mode.
This might be a controversial statement, but I lean towards monitoring a very small slice of an environment, but making each alert very meaningful. If I get bitten by something I didn't anticipate, then I add an alert for it.
Bear in mind that I only have about 50 queue managers and they are all similar, so this granular approach works for me.
I have supported larger, more diverse environments and there I did do somewhat more generic alerts. But I still was very conservative with alerts.
I have seen so many admins who have pagers that beep constantly with useless alerts, to the extent that they start to ignore the beeps. |
|
| Back to top |
|
|
|
|
