Re: Monitoring XMIT queues

Thu, 10 Feb 2005 07:50:10 -0800

Peter,

 

  I agree with you.

 

  The way I monitor channels in retry is that I’ll alert 15 minutes after the retry status. That way if it is network blimp, then the channel will reconnect in that time period and I can continue to sleep. The 15 minutes also gives enough time for the remote queue manager to come back up after the server it resides upon has been recycled.

 

  Why lose any sleep if you do not have to?

 

 

HTH,

 

John Dawson

 

 

 

-----Original Message-----
From: Potkay, Peter M (ISD, IT) [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 10, 2005 9:43 AM
To: [email protected]
Subject: Re: Monitoring XMIT queues

 

:)

 

Does a tree make a sound if it falls and no one is there to hear it?

Does it matter if a channel fails and there is no message in the XMITQ anyway? (assumes the channel will retry and fix itself - why get paged at 2 AM if it fixes itself and no one is effected?)

 

We went round and round on this one. I can see that point, but we ended up just watching the XMITQs. Sophisticated MQ monitoring  tools like QPASA allow you to combine the 2 methods, which is probably the best, i.e if the channel is not RUNNING AND the XMITQ queue depth is >0 and the dequeue rate is less than x per minute, then page. Otherwise, let it fix itself.

 

 

 

-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, February 10, 2005 10:30 AM
To: [email protected]
Subject: Re: Monitoring XMIT queues


Wouldn't it be better to raise an alert if your channels fail instead?  It's the channels that drain the xmitqs and a buildup on the xmitqs is just a side effect.


"Williams, Dave (Systems Management)" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[email protected]>

02/10/2005 10:05 AM

Please respond to
MQSeries List <[email protected]>

To

[email protected]

cc

 

Subject

Monitoring XMIT queues

 

 

 




Hello... How are folks monitoring XMIT queues for page alerts? Seems to
me that if the depth of an XMIT queue was on the rise, but had
intermittent decreases there is no need to be paged - if however there
was an increase w/no decreases, that would be a problem and a page would
be warranted. A friend suggested we use ' Service Interval High' to key
off of, but I'm not sure what to code in Omegamon to do this.

Ideas... Suggestions?

Thanks,

Dave W.              

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com 

Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html






This communication, including attachments, is for the exclusive use of 

addressee and may contain proprietary, confidential or privileged 

information. If you are not the intended recipient, any use, copying, 

disclosure, dissemination or distribution is strictly prohibited. If 

you are not the intended recipient, please notify the sender 

immediately by return email and delete this communication and destroy all
copies.
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com 
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com 
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Reply via email to