| Author |
Message
|
| EB |
 Posted: Wed Mar 30, 2005 6:55 am Post subject: Candle (Omegamon XE/DE) situation. Help needed... |
 |
|
Acolyte
Joined: 19 Mar 2004
Posts: 70
|
Hi
I am trying to set up the following scenario:
------------------------------------------------------------
For spesific queues (holding messages) I want to monitor if the oldest message is more than 10+ min old and if last read was more then 10 min ago.
The oldest message can be identified by using the Message statistics attribute group in the situation.
The last read can be checked with the queue statistics attribute group.
I have not been able to find a way to combine the two attribute groups thus I hade to build 2 situations.
So what I need to do is to monitor for both situations to be true and then send/generate the alert.
I made 2 management situations, one for each monitoring situation to trigger a policy which in turn is supposed to generate alert mails.
Now taken in to concideration that this monitoring scenario repeats itself for quit some queues (message statistics attribute group can only monitor one queue at a time), I will be stuck with alot of situations and policies.
What am I missing, there has to be a better solution.
------------------------------------------------------------
Any advice is greatly appreciated
Regards
EB |
|
| Back to top |
|
 |
| mqjim |
| Posted: Wed Mar 30, 2005 7:09 am Post subject: MQSeries Monitoring/Tools |
|
|
Novice
Joined: 01 Jul 2004
Posts: 22
Location: TEXAS
|
| Using a policy you can combine situstions. Each situation tied to the policy would be seperate from another. If you may need to create several policies to use the situations. Just a thought. I do not have access to the Candle product at this time although calling the help desk or using the ablity to open a ticket online ask they for help. This should be resolable, also If you have an account rep have then ask for you this will get quicker turn around. |
|
| Back to top |
|
|
| EB |
| Posted: Wed Mar 30, 2005 7:18 am Post subject: |
|
|
Acolyte
Joined: 19 Mar 2004
Posts: 70
|
Hi mqjim and thanks for the rapid reply.
Yes I know that we ca tie together situations in a policy but you need management situations as well to catch the messages from universal console. This leaves me with at least 4 situations and 1 policy for each queue I want to monitor this state for. I hope that there is an easier way to combine the states (msg older than 10min and last read more than 10min ago).
I can ofcourse contact IBM helpdesk but speaking from experience this takes some time, so I hope that someone in this forum can help.
Regards
EB |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 30, 2005 1:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Instead of speaking in terms of what you want to monitor can you please describe the business case?
There probably is more than one way to skin that cat.
 |
|
| Back to top |
|
|
| EB |
| Posted: Thu Mar 31, 2005 1:57 am Post subject: |
|
|
Acolyte
Joined: 19 Mar 2004
Posts: 70
|
OK I try to describe.
I will receive a quantity of messages on a queue. The que is monitored by a listener (java) wich in turn will get the messages of the queue synchroneously. Now If the listener fails there will obviously be a buildup of messages on the queue, the thing is there can also be a build up of messages due to workload where the listener works fine. Therefore we have set a 10min limit, which in our case fits.
So if there is a message on the queue older than 10min AND the listener hasn't done a get for 10min this would indicate that actions have to be taken. It is this scenario we want to monitor.
I hope this made sense.
Any suggestions are greatly appreciated
Regards
EB |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 31, 2005 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Putting a listener to the queue is not enough as you have experienced.
Have you tried to add an errorlistener as well ?
This should monitor as to when / why your connection goes down and the listener is no longer effective.
An other possibility is to have the queue triggered. (no use of listener just receiver)
Write the triggered process as as if it is triggered first. If you need more horse power you can run it as triggered every.
Remember to set the trigger interval to something sensible (300,000=5 min) and if you change it, to recycle the queue manager.
If you have a client trigger monitor it would be prudent to have an error listener on the initiation queue.
In any case monitor for the following:
No process doing gets from the initq and
No process doing gets from the queue and queue depth > 0
Hope this helps some and gives alternate solutions.  |
|
| Back to top |
|
|
|
|
