| Author |
Message
|
| Challenger |
 Posted: Wed Feb 04, 2009 12:25 am Post subject: Challenge Question - 02 / 2009 |
 |
|
Centurion
Joined: 31 Mar 2008
Posts: 115
|
| Quote: |
"The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why and Where phases.
For instance, the first phase is characterized by the question How can we eat? the second by the question Why do we eat? and the third by the question Where shall we have lunch?" |
Douglas Adams, "Hitchhikers Guide to the Galaxy"
I believe the goals of monitoring, and in particular Middleware monitoring, have the same the three levels:
1) Is the Middleware actually there?
2) Is it working?
3) Is it working well?
MQ is a wonderful product, but lacks one vital element necessary for smooth business running - a management package to control it. Practically the only interface available is via commnd line processor and a half-hearted explorer that comes free (you get what you pay for )
So, what do you want from an MQ management package?
This is not a "let's compare vendors offerings and say which ones are our favourites" type of question (although vendors are welcome to offer their no hype Technical opinions)
but more, what do YOU want and why?, And what YOU don't want and why?
I'll score the answers based on the following scale:
1) Basic obvious facilities - 1 point
2) Slightly less obvious facilities - 3 points
3) Off the wall facilities but actually really really necessary - 10 points
4) Facilities you don't need (and why) - 4 points
5) And finally, facilities you positively want to remove (and why) = 8 points
The Challenger's scoring and winner decision is final 
Challenger ! |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Feb 04, 2009 6:32 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I want to quickly and easily know that all my QMs are happy and healthy. Not just because that there are no active alerts, but something proactive that the tool is doing behind the scenes, connecting to all QMs, sending and consuming messages down all QM to QM channels, etc. I scripted something like this, but out of the box would be nice.
Knock MSFT all you want, but one thing I liked during my brief stint of managing the SQL Server team was their MOM monitoring. MSFT has a SQL Server MOM "module" that immediatly gives you 100% comprehensive SQL Server monitors, written by the people that best know SQL Server, the SQL Server people. I would love to see IBM have a monitoring module that out of the box gave you comprehensive monitoring for all things MQ and WMB. It would alert you if the Repository Manager went down, if an FDC was cut, if an Execution Group went down, if a Listener failed to start, etc, etc, etc. The individual customer would then be free to turn off alerts they did not care about, and set the alerting method and frequency. I am sure most of us don't monitor for everything we should, either because we don't know, or don't have the time, or don't have the tools to implement what really should be happening.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Feb 04, 2009 5:32 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
I want to know that MQ clusters are healthy. That there are no inconsistent clustered queue definitions (DEFPSIST etc) on any qmgrs. That all cluster channel defs are valid and not in retry. That the full repository qmgrs are running and have the same info. That the cluster config agrees with what we think it should be (no rogue qmgrs or missing qmgrs).
_________________
Glenn |
|
| Back to top |
|
|
| AkankshA |
| Posted: Wed Feb 04, 2009 9:26 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
Some obvious ones : to be specific
GUI based on IE, no more installations at client side pls
Auto-Discover/Search of MQ queue managers on connected node
Show me QM's are healthy and channels/listeners are up and running
Color queues based on GET/PUT disabled/enabled
Alert on security loopholes like SVRCONN channel MCAUSER being set to mqm
Continuous Monitoring of error logs and show me the brief about failure cause... ie. shd not give me stack trace but exact mqrc and description
Show me the message present in queue without hexadecimal prefixes
Allow me to test connectivity and put msgs along with configurable MQMD/MQRFH2
Cluster, warn me when a QM has two entries with FR....
SMS configurability for high priority alerts
SECURITY : Clicking on a QM/its object shall display me all the users/groups having type of accesses on the object... dspmqauth needs too many info... 
Display me the CSD level of Remote MQ QM...
Able to format trace and show me..
Able to show me my JMS configured objects (Q's and QCF etc)
_________________
Cheers |
|
| Back to top |
|
|
| Challenger |
| Posted: Sat Feb 07, 2009 1:00 am Post subject: |
|
|
Centurion
Joined: 31 Mar 2008
Posts: 115
|
Some good ones here, I particularly like Ashankas idea of flagging SVRCONN channels with "mqm" as the MCAUSER - and the health checkers for QMs and clusters from gbaddeley and PeterPotkay
I'll throw in an in idea of my own (but I won't give myself any points ) - in our shop we use a lot of sender/receiver channels, and if we move (point DNS entry to new hardware) or rebuild the queue manager we always get channel sequence number errors - we know we're going to get them, we fix the sender side pre-emptively but the receivers we normally have to get the other end to reset (who might be in a different timezone/division/company and unwilling to do so, especially at weekends) or wait until their end starts up and match their sequence number. I know we could fiddle about with saved channel statuses but it would be nice just to flag a channel, one-time, reset the sequence number to whatever's in AMQERR01.LOG as we know it's going to happen
Last edited by Challenger on Sun Feb 08, 2009 9:19 am; edited 1 time in total |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Feb 07, 2009 2:53 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Challenger wrote: |
| ...it would be nice just to flag a channel, one-time, reset the sequence number to whatever's in AMQERR01.LOG as we know it's going to happen |
This could also be one for the MS03 SupportPac, i.e. save the sequence number and write the reset command immediately after the channel define.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sat Feb 07, 2009 4:07 am Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Challenger wrote: |
| Some good ones here, I particularly like Ashankas idea of flagging SVRCONN channels with "mqm" as the MCAUSER... |
This fits into an area called Security Compliance. There are more than a dozen fairly simple checks that can be done to ensure that no one has access to authority they shouldn't have.
In Ashankas suggestion, it should really check for MCAUSER being blank or any user that has MQ administration authority.
_________________
Glenn |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Feb 07, 2009 4:11 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gbaddeley wrote: |
| In Ashankas suggestion, it should really check for MCAUSER being blank or any user that has MQ administration authority. |
Which could get very convoluted as it would need to query mqm Group membership, and on Windows...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Feb 07, 2009 6:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| gbaddeley wrote: |
| In Ashankas suggestion, it should really check for MCAUSER being blank or any user that has MQ administration authority. |
Which could get very convoluted as it would need to query mqm Group membership, and on Windows... |
Right, but we're talking about an MQ management package. It's not clear how something can manage MQ without being able to manage and audit mqm/domain mqm membership. Wouldn't you like to get an email in the middle of the night when some random AD administrator decides to make "Domain Users" a member of domain mqm? |
|
| Back to top |
|
|
| jcv |
| Posted: Mon Feb 09, 2009 10:05 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| exerk wrote: |
| Challenger wrote: |
| ...it would be nice just to flag a channel, one-time, reset the sequence number to whatever's in AMQERR01.LOG as we know it's going to happen |
This could also be one for the MS03 SupportPac, i.e. save the sequence number and write the reset command immediately after the channel define. |
Same idea occured to me, but when I checked switches for ms03 and spotted -R, I thought such option is already present. After checking what it does (it creates reset commands with fixed SEQNUM(1)) I started to doubt, why someone who created that option didn't have the same idea ... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 09, 2009 10:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's not clear that there's a lot of value in using a specific sequence number or a default sequence number (1).
The only time you need to use the "right" sequence number is when resetting the receiver side of a channel rather than the sender side. And if saveqmgr is saving the qmgr that has the receiver, it has no information about what the right value on the sender is.
I"m happy to listen to arguments or discussions either way, in a new thread, if someone wants to start one. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 09, 2009 11:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...value in using a specific sequence number or a default sequence number (1). |
This (RESETing a channel) falls into the category of a great technical solution, but not-so-great practical business solution. Yes, I can get the channel running again; but what of the messages that appear to be lost?.
What number to pick to force synchronization is usually based on determining if the messages were successfully comitted or not. It's clear that the channel is confused.
A well-behaved application should be sensitive to missing/duplicated messages...
Meet y'all in the new post for this.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Challenger |
| Posted: Tue Feb 10, 2009 1:36 am Post subject: |
|
|
Centurion
Joined: 31 Mar 2008
Posts: 115
|
So, to summarize so far, we seem to have two camps:
1) General health check on the queue manager and/or cluster it is a member of;
2) A "probe test" to look for weak spots in security, particularly regarding SVRCONN channels |
|
| Back to top |
|
|
| Mehrdad |
| Posted: Thu Feb 12, 2009 12:04 am Post subject: |
|
|
Master
Joined: 27 Feb 2004
Posts: 219
Location: Europe
|
seems like a remidner is needed that this topic is Feb's challenge.
Here is the current state of things :
| Quote: |
So, to summarize so far, we seem to have two camps:
1) General health check on the queue manager and/or cluster it is a member of;
2) A "probe test" to look for weak spots in security, particularly regarding SVRCONN channels |
|
|
| Back to top |
|
|
| tkane |
| Posted: Mon Feb 16, 2009 2:23 pm Post subject: |
|
|
Voyager
Joined: 23 Dec 2002
Posts: 82
Location: Kansas City
|
I'd like to be able to configure real monitoring thresholds for queues based on time of day and day of week.
For example, queue A is for an online CICS application and if application XYZ dumps 500 messages into it before online hours that's fine. But if it's inside the online day, that queue should be empty or nearly empty.
Oh, and if it's above the threshold, notify the CICS application's support group. NOT the MQ Support group.
Sample every x minutes and in some cases, we'd like it to be alarming for 2 or 3 times in a row before you actually notify out. That evens out some of the hills and valleys.
Support all platforms (hey, we have PCFs in zos now)
In other words, lots of options on configuring depth alarms, with lots of notification interfaces and support for many queue managers (hundreds) and tens of thousands of queues. |
|
| Back to top |
|
|
|
|
