| Author |
Message
|
| PeterPotkay |
 Posted: Mon Nov 03, 2003 5:12 pm Post subject: Anyone using the SiteScope MQ monitor from Mercury? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Just curious if you like / dislike it. I will be evaluating it soon and wondering if it is worth my time.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| vennela |
| Posted: Wed Nov 05, 2003 12:37 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Oct 26, 2004 3:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Well, within a few months my MQ monitoring WILL be done by SiteScope. Anyone else using it yet? Looks preety cool. Nice Web interface.
One drawback I see is that it, a Java Client, connects to the QM to look at event queues and drop PCF messages. You can configure how often it does this per monitor. The problem is for a QM with 500 monitored queues, and my monitor frequency set to 1 minute, I am going to incur 500 connects disconnects per minute. Just by the monitoring tool. On top of all the real work the QM is doing. Don't know yet if I should worry about this.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Oct 26, 2004 8:24 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
In my humble opinion, the only things that really need to be monitored on an MQManager are:
A. The general health and well being of the MQManager/s themselves.
2. Monitor for any Channels that end abnormally, AMQ9999.
III. Monitor for CURDEPTH of greater than 0 in your DLQ.
If a QLocal is filling up, it's an application problem. Application problems should be monitored in the application logs not on the MQManager.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 27, 2004 5:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
As an Enterprise, we do not want hundreds of different apps monitoring themselves a hundred different ways, each buying their own tools.
To save money and for the sake of consistency, we want to consolidate our monitoring to as few tools as possible, maintained by a single group in the company responsible for monitoring.
But I do see your viewpoint. I'm always saying "If an app's queue is filling up, it is not an MQ problem."
That does not preclude the company using one method/tool to alert the proper people in each scenario of any queue crossing a threshold. Anytime a new app comes onboard they should not have to reinvent the wheel, i.e. figuring out how to monitor queue depths and then how to open tickets in the Remedy system and then how to page people, etc, etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 27, 2004 5:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I thought you were sold on QPasa?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 27, 2004 5:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You had to go there....... 
Yes we have QPASA, but was bought for its ability to help developers manipulate messages. Its monitoring capability, to us, was extra functionality that was not a primary consideration for buying the tool. Yes, I know it is consider a monitoring tool pimariliy.
That was then. Now, the right people are looking at things the right way. I have brought up the fact that QPASA has excellent MQ monitoring, and why aren't we just using it. "Well, we bought Sitescope, its MQ is included, etc."
Put it this way, we (actually "they", the monitoring team) are looking at the issue. Fact is we have 2 tools that are here to stay, and both have MQ monitoring capability. The MQ team has input to what is used, not the final say.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 27, 2004 6:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| Yes we have QPASA, but was bought for its ability to help developers manipulate messages. |
I have to think that MQVE would be cheaper...
And you still do all your MQ management with a support pack, right?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 27, 2004 6:32 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Yup, I was thinking of Roger as I wrote that sentence. But MQVE was just a twinkle in his eye when we were making that decision!
For MQ admin, each team member has their preferance. I use MO71, others love MQExplorer. Both, I believe, are better MQ Admin tools than QPASA. Not that QPASA lacks functionality, but that the others are more user friendly in day to day activity.
The next major release of QPASA is supposed to address this I think.
Then we have that mainframe guy who uses TSO panels instead of MO71 when the QM is a mainframe one....weirdo. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 27, 2004 1:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter,
We do not use QPasa as an MQAdmin tool (Well we do use some nifty things like save qmgr from QPasa) but primarily as a MONITORING tool.
I ended up writing a script that checks 43 queues and emails the ones that do not have a 0 depth to the management. This happens twice a day.
We have a number of cockpit views (logical views) that allow us to have a quick overview of the health of a specific part of the system....
Of course on top of that we do use all the alerts like DLQ > 0 and channel retrying.....
I agree that if the number of your MQ Admin guys is restricted you can use other tools for admin (even runmqsc). If you need accountability as to whom changed what use QPasa as well as admin tool.
I know you have little say in which tool will ultimately be used. Just remind your folks of the QPasa plug ins for Tivoli and HP system monitoring....
Enjoy
F.J. |
|
| Back to top |
|
|
| webspherical |
| Posted: Thu Nov 03, 2005 11:45 am Post subject: |
|
|
Acolyte
Joined: 15 Aug 2005
Posts: 50
|
Hey Peter,
We are trying this SiteScope monitoring also.
It appears we have everything setup properly on the box with sitescope WMQ5.3.10 and the pcf jars etc, but when trying to connect to the remote Qmgr that we want to monitor we continue to recieve 2059 (qmgr not avail) but the Qmgr is definitely up and running, so is the command server and listener for the qmgr. using SYSTEM.ADMIN.SVRCONN.
any idea? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 03, 2005 7:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We actually ended up using QPASA! 
SYSTEM.ADMIN.SVRCONN is definitly defined on the QM?
Are you sure you are specifying the correct hostname and port#?
Can another tool / program get to this QM over that channel?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Nov 04, 2005 1:11 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| fjb_saper wrote: |
| (Well we do use some nifty things like save qmgr from QPasa) |
| fjb_saper wrote: |
If you need accountability as to whom changed what use QPasa as well as admin tool |
F.J.,
can you elaborate on what QPasa offers on the points above?
- what nifty save qmgr (what makes it more niftier then ms03)
- how does QPasa tell you who changed what? (i.e. does it detect
someone changing something through runmqsc?)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 04, 2005 4:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Michael Dag wrote: |
| fjb_saper wrote: |
| (Well we do use some nifty things like save qmgr from QPasa) |
| fjb_saper wrote: |
If you need accountability as to whom changed what use QPasa as well as admin tool |
F.J.,
can you elaborate on what QPasa offers on the points above?
- what nifty save qmgr (what makes it more niftier then ms03)
- how does QPasa tell you who changed what? (i.e. does it detect
someone changing something through runmqsc?) |
- It is not "better" than MS03 but easier to use and more intuitive...
-You do not need to give runmqsc rights to anybody. Just force the developers to use QPasa configuration console and the changes will be logged with their user ids. You have as well more granular control over what they are allowed to change with less groupID management at the OS level. You should however have a separate DEV and PROD server as the rights are the same. The alternative is to secure the agents and add security at the OS group level in MQ.
Enjoy
 |
|
| Back to top |
|
|
|
|
