| Author |
Message
|
| JohnRodey |
 Posted: Thu May 11, 2006 6:58 am Post subject: Monitoring the Listener |
 |
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
We are looking for a way to monitor the mq listener.
We could create an application to monitor that pid, but then how do we monitor that application? I guess something like veritas could achieve this but a bit pricey and possibly overkill. Does MQ offer any support packs for this or does Unix offer this capability.
Running MQ 5.3.10 on Solaris.
Any help is appreciated!
Thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu May 11, 2006 7:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can script amqscnxc to periodically connect to the listener.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 11, 2006 5:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| You can script amqscnxc to periodically connect to the listener. |
2 birds with one stone. U monitor the QM as well. I assume he only cares about the listener if the QM is up as well.
| JohnRodey wrote: |
| We are looking for a way to monitor the mq listener. |
Why? Is it crapping out all the time?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| vennela |
| Posted: Thu May 11, 2006 8:37 pm Post subject: Re: Monitoring the Listener |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| JohnRodey wrote: |
| I guess something like veritas could achieve this but a bit pricey and possibly overkill. |
Why not cron it.
Also, if listener not found and if the port is not being used try starting it before sending out an alert.
| JohnRodey wrote: |
| Does MQ offer any support packs for this or does Unix offer this capability. |
There are some support packs which have monitoring scripts but writing a simple one on your own is a trivial task. Again, in UNIX cron can do this, like for example every 2 minutes. |
|
| Back to top |
|
|
| JohnRodey |
| Posted: Mon May 15, 2006 10:44 am Post subject: |
|
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
Peter, no its not crapping out all of the time. As a matter of fact it has never crashed. Although we have a requirement to handle every single point of failure. So even though it doesn't, it could.
Vennela, we could use cron but even every two minutes is too long. I was wondering if there was anything that was (virtually) instantaneous. I guess we could use cron at a 1 second interval or something. I was just wondering if there was a way to do something at an operating system level when a pid dies.
thanks! |
|
| Back to top |
|
|
| vennela |
| Posted: Mon May 15, 2006 10:51 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
I would say every second is an overkill.
A minute should be pretty reasonable if not 30 seconds. But less than that is too much of an overkill.
| Quote: |
| I was just wondering if there was a way to do something at an operating system level when a pid dies. |
Not that I know of. Even if there was one it would be pretty hard to configure because every time you start the listener, you need to update the PID and whoever does it, has to know what they are doing. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 15, 2006 2:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| JohnRodey wrote: |
Peter, no its not crapping out all of the time. As a matter of fact it has never crashed. Although we have a requirement to handle every single point of failure. So even though it doesn't, it could.
|
So could your monitoring solution. What's gonna monitor that? And whose to say its more stable than runmqlsr? 
I think amqscnxc a few times a minute would suffice......
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JohnRodey |
| Posted: Tue May 16, 2006 5:46 am Post subject: |
|
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
| Quote: |
| So could your monitoring solution. What's gonna monitor that? |
Our requirements are to prevent single point of failure, so if both are down at the same time then that is acceptable.
Our problem is that we have applications receiving messages from the primary QM and they retain their connections. If the listener goes down then all sending application will not connect to the primary and instead connect to a backup QM... Although there may be nobody receiving those messages because they are all still receiving from the primary (because they still have connections).
If we only check once a minute then for an entire minute we will lose all of those messages, and if any of those sending apps need responses they will be hanging out forever on the backup QM.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 16, 2006 7:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| JohnRodey wrote: |
| we will lose all of those messages, |
Why?
Are they non-persistent messages?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 16, 2006 5:26 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| JohnRodey wrote: |
If we only check once a minute then for an entire minute we will lose all of those messages, and if any of those sending apps need responses they will be hanging out forever on the backup QM.
|
You're not gonna lose anything, even if the messages are NP, just because a Listener goes down.
What are you trying to get to happen once your monitor says "LISTENER DOWN on QM1!!!"? All the SNDRs should on their own start using QM2 (you are using MQ Channel tables?)? Or logic in the app to immediatly try QM2 if QM1 returns a 2059 on the MQCONN? And then somehow you are going to force all the receivers (and already connected senders, don't forget about them!) to disconnect from QM1 and reconnect to QM2?
ugh, this is bad news and will always have an opportunity for problems. Personally, if the above is the goal, I would prefer you put both QM1 and QM2 in a cluster, have the local queue defined on both QM1 and QM2, and have 2 instances of the app reading from each of the local queues on QM1 and QM2. That way if you lose a QM, a listener, and/or a receiving app, you still got one queue live and being serviced. The senders can connect via MQ client channel tables to either QM1 or QM2 and you can still load balance the messages if you are at MQ 6.0 without a third QM acting as a gateway to round robin.
You could also just forget about the clustering and load balancing, and have the receivers on QM2 watching a queue with nothing arriving unless or until there is a problem with sending to QM1 (scheduled ot unscheduled outage)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| lbart |
| Posted: Thu May 25, 2006 6:54 am Post subject: Tivoli Omegamon |
|
|
Novice
Joined: 18 May 2006
Posts: 13
Location: Manchester
|
You could use the Tivoli Omegamon solution but not the MQ one, you would need the operating system one e.g. Tivoli Omegamon monitoring agent for Aix you can then monitor the listener process from a unix perspective, you can also create situations (alerts) to monitor for it going missing or not being present.
Cheers
Lee |
|
| Back to top |
|
|
|
|
