| Author |
Message
|
| robsdman |
 Posted: Tue Jan 25, 2005 5:34 am Post subject: Are MQTools more complicatd than the MQ Env being monitored? |
 |
|
Apprentice
Joined: 23 Aug 2002
Posts: 27
|
Be Honest, what % time is spent configuring MQ Tools vs MQ setup itself?
What percent of time are you MQ Admins actually spending on configuring these wonderful Tools?
Be realistic, because in my observations many these tools are 3 and sometimes 4 tier. Having agents, nodes, managers, web servers, event loggers, databases, etc.
While the core MQ Production systems they are monitoring are merely 2 and 3 tier.
I cringe at the thought of installing some of these monitoring solutions.
Maintaining their software, upgrades, testing..pushing through the lifecycle systems....uuurrggg...
I feel like I am the only one seeing this?
Does anyone have some wisdom to enlighten me?
Maybe I'm lost...
Maybe I haven't seen the right tool yet...  |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jan 25, 2005 5:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Configuring a monitoring environment is definitely a significant investment in time.
But think about what you're doing. You're modelling your business systems, and providing rules and intelligence to enhance that model.
Also, yes, most monitoring tools are composed of many components. This is actually a good design practice. Agents that run on production servers should be as light weight as possible, to avoid causing the same kinds of problems they are trying to watch for!
Having a database in the mix is the best way to provide information for analysis and reporting.
And a web component is the best way to provide enterprise wide visibility of the model and the reporting/analysis.
All that said, however...
Some tools have a much lower "time to market" than others.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| robsdman |
| Posted: Tue Jan 25, 2005 10:12 am Post subject: |
|
|
Apprentice
Joined: 23 Aug 2002
Posts: 27
|
Jeff,
You have good responses. But we all know the wonderful things Monitoring provides. It's Great Stuff.
But to get back to my point, let's take the "ping" command.
If any given app is not talking to the server, we usually do a quick ping check, seeing if the server is reachable.
Well, okay...suppose now...
We take this ping command and pour $5 million into development for a new monitoring tool, "The Pinger". This will give us Great Stuff: Critical Production System Views, color coded, configurable layouts. We configure WAS 6.0, SQL Server, agents running on each the nodes, node managers, ping alerts, ping statistics, ping graphics and analysis, historical tracking.....what else..
It takes 1 month to install "The Pinger"
Takes 2-3 weeks for major upgrades.
Each upgrade has to be be pushed through the lifecycle process.
Coming from my perspective, a simple MQ Guy, I am very skeptical of these large MQ Monitoring packages.
I think many of us are looking at the worm while loosing site of the hook.
Time to post a new question... |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 26, 2005 12:11 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| I agree - the complexity of setting up one of the big packages doesn't seem worth it at times. We are a large MQ site and we have managed for ten years without any major MQ system management tools. We have some in-house Java programs that provide alerting on queue depth. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 26, 2005 4:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The return on investment of all the glitz does have to be taken into account.
But you also have to realize that the data that these systems can track is not limited in usefulness to MQ Administration - there can be a lot of business information that is "hidden" in this data.
Queue depth history, for example, can be a critical measure of application performance - which can very easily equate to dollars of business.
Also, reduced downtime and reduced staff effort can be a huge cost savings. If I spent three months implementing a monitoring tool, and after that I never suffer more than ten minutes time-to-resolution, then that might be big. And enabling operational staff to resolve problems PROPERLY - because you have modelled your infrastructure and your resolution strategies... can mean things like IT Managers not getting paged at home, or having to pay overtime or comptime to senior admin and development staff...
And I wonder how long it takes to push upgrades to ZPat's in-house software, too.
Also, with a proper three-tier architecture... you rarely need to upgrade the agents on production boxes - so it can be a lot easier to perform upgrades of monitoring tools.
Like any other IT system, monitoring tools need to be considered from a business point of view as well as a technical point of view.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 26, 2005 6:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| robsdman wrote: |
| We take this ping command and pour $5 million into development for a new monitoring tool, "The Pinger". |
You are not paying 5 mil for a pinger. If all you want is a pinger, it is cheaper and easier to write it yourself.
You are paying the 5 mil for all the other stuff that come with the package. It is not the monitoring companies fault for including features you don't use.
But I agree, somedays it feels like I got 100 better things to do then mess with the monitoring tool....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQueue |
| Posted: Tue Aug 02, 2005 1:42 pm Post subject: |
|
|
Newbie
Joined: 02 Aug 2005
Posts: 1
|
| I agree with robsdman. We just setup an MQ cluster this afternoon which went rather smooth. After which I wanted to looking into tools to do some basic monitoring functions (basic being the keyword) but everything I've come across so far seems to be twice as complex to setup the cluster and provides a lot of stuff that I just don't need. Does anyone have a tool that they would recommend? One that: Well not take me 2 weeks to setup... Well not require me to purchase more hardware to run it than what I'm using in my MQ cluster... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 02, 2005 5:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The crux of a good monitoring tool is:
a) to be out of bandwidth so as not to slow down the primary functionality
b) to alert you even when the main application you are monitoring is down. Or the monitoring agent is down.
O.K. you can look at this as a sophisticated "pinger" but imagine this:
Coming back from the middle of the night automatic maintenance window
MQ won't start. Network and connectivity are O.K.
The queue manager won't start. (You get the drift...)
c) to be able to set up customized alerts and reporting
Like email the queue depth accross 3-5 platforms for over 80 queues
twice daily for management
d) To report on past events and statistics
MAX queue depth over time
Number of messages processed during an interval
Performance and throughput information
Sizing information through stress testing
etc....
Yes you could do some without the tools. But why make your life so much more complicated when you can run stuff at 3:00 AM and come in the next morning at 9:00 AM and still have an acurate evaluation of the results...
Is the money worth the setup effort ==> I certainly think so. Especially when it contributes to the smooth sailing and takes a brick of a load off of your shoulders as the MQ admin.
Enjoy  |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Tue Aug 02, 2005 10:40 pm Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
I think you could say the same about documentation.
As soon as you press the save button in your textprogramm it is already old. Writing documentation is not the most exiting thing I can imagine, but is necessary.
| Quote: |
| Like any other IT system, monitoring tools need to be considered from a business point of view as well as a technical point of view |
I realy like this statement Jeff. Because I think it is the answer to the entire discussion.
If you run on an enterprise level, and your businesses rely on that your MQ is moving messages from the orders system to the Production control system, then you should certainly Monitor somehow.
We have some customers that are doing EDI orders. And if they are not delivered within 48 hours, we can keep our goods. In other words it cost money.
Other example, if a truck is standing there packed, and can not leave because your delivery receipt is stucking somewhere in a dead letter queue, this can also cost money.
I see monitoring rather as a protection against business worst cases. Maybe the ROI is to some extend even something 'invisible' if it comes to monitoring.
Well I agree that if you run a backery, and the worst thing that can happen if something goes wrong, that the guy at the cashier, is not getting his morning coffee, a complete Monitoring/System management... solution might be over the top. Then your own handwritten ping tool will certainly do.
But to me the thing that you really need to consider when making this decission is what money the business can loose, what the maximum time is they can wait for a message etc.
My opinion is that setting up a system is always only a small percentage of time. Troubelshooting should not be too much.
But writing documentation, monitor and all this Admin crap is taking time. Loads of time.
And the benefit of those complete management systems is clearly that they are out of the shelf. You get proper support, but you need to invest some time in them. Your own solution, might or might not work. But nobody can realy guarantee that and you might end up shooting yourself in the leg.
Then some managements want to see performance statistics. In most of the complete solutions this is already integrated.
So back to the original question:
Yes it is a painfull and anoying Job.
Is it worth it? In many cases yes, in some cases no. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Aug 02, 2005 11:54 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| jefflowrey wrote: |
And I wonder how long it takes to push upgrades to ZPat's in-house software, too. |
The answer is that these tools have never needed code updates for new MQ versions, the configuration files (ie which queues to check, which thresholds for alerts etc) are easy to update. |
|
| Back to top |
|
|
| chuck_nc |
| Posted: Thu Aug 04, 2005 8:02 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2005
Posts: 2
|
I would guess that your MQ environment is rather small and not much business depends on it. Keyword here, "business". It used to be, the technology drove the business, now the business drives the technology. It's very simple, what is your threshold for pain? If you can live with a downtime of 1 hour and it does not effect your business (i.e. revenue), then you probably don't need a monitoring tool.
Companies invest millions of dollars in monitoring business applications and the components that make them work. Studies have been done that prove monitoring tools actually do save companies money. In some cases, it makes them money (i.e. chargeback for MQ usage)
I understand your perspective. I was a sys admin for many years, in the past 3 years I have come to understand that there's a lot more than MQ in the big picture. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 04, 2005 8:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We have about a dozen mainframe QMs, several dozen non-mainframe QMs and several thousand MQ clients. The MQ based business transactions are worth several billion USD a year, but we manage very well with our in-house queue monitor.
I have actually wanted BMC patrol or such-like, it's always fallen foul of some sort of budget or outsourcing argument - eg IBM run the QMs so why should we pay for tools to make life easier for them!
It comes down to the old maxim "if it ain't broke - don't fix it"! By maximising MQ client use and having as few as possible queue managers it does make it manageable without complex products.
Most of our apps are MQ client based synchronous request/reply - there is really nothing to manage, queue depths don't build up and there is nothing to go wrong really.
We have a large WBIMB broker as well - but again it all works pretty well - the key is to have high quality designs that are engineered to be as reliable and self-healing as possible.
The in-house tool monitors queue depths on certain queues to catch any exceptions to this and sends alerts. It just inquires on the queue using the MQI so it will not be affected by MQ release changes.
Last edited by zpat on Thu Aug 04, 2005 10:41 pm; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 04, 2005 10:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I expect that your applications have a high degree of monitoring/logging built into them.
MQ can be treated like just another transport or network layer - nobody really extensively monitors and tracks TCP/IP traffic - provided you have enough monitoring going on for the important stuff.
But a lot of shops prefer not to invest development time into building a business level monitoring infrastructure or coding apps to fully populate that.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Aug 04, 2005 10:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I can guarentee you that implementing a large MQ system management infrastructure will take a lot of time and cost a lot of money. Software for mainframes especially can be incredibly expensive.
Our Java probe took about 2 weeks development time and has never needed any maintenance. There are a lot of vested interests around selling "solutions" - but keeping things simple is the best approach.
Of course our outcome would not necessarily be right for everyone. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 04, 2005 10:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| zpat wrote: |
| Of course our outcome would not necessarily be right for everyone. |
Particularly as, at least it seems to me, you are only doing basic uptime checking, and you are not gathering business intelligence.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
