Yowza! 20% of the companies in our space have a monitoring solution!

In this space I had two issues/concerns.

1) The impact of any monitoring agent on performance

2) The amount of data collected and what to do with it.

Let's take the example of Citrix Edgesight to illustrate. I like the technology and the concept of historic reporting etc. However the agent can impact performance when users are busy, and I had to play around with config a lot to figure to get it to work right. Even then there are instances I just simply turn it off. It collects so much information that often it send me off on wild goose chases that lead nowhere. Granted there are times where it did nail my problem. As a result I tend to use tools like Edgesight on an Ad-Hoc basis for troubleshooting. For that I'd prefer to have a perfmon like ability where to large groups of machines I can simply turn on counter x,y,z. Too cumbersome today. The reporting history is great, but never how I want it. The fact it leverages MS Reporting Service helps, since I can write my own reports and have operations consume them, however I just can't get our operations YET to do the right thing. They are just not very smart and stupid management.

As for many of others, MOM etc, I am just tired of email alerts. WAY too much noise that fills up my inbox.

So in general critical alerts are useful, but monitoring is mostly noise. What is needed is a way to rationalize all the noise and detect variance in patterns from the norm. Then the system can decide if something is worth bringing to my attention. Without that type of capability, I see limited value in my experience.

I pretty much spent most of the 90's making monitoring products for the communications industry space.  While I am tired of these products, you do have to have something around.

They are very helpful when you want to change things and they are helpful when something is broken.  In between they represent overhead.

The argument for running them in between is always one of "how do you tell what changed if you don't monitor in-between".  In theory, you could write really good software to figure out what is important and what isn't.  But most of the time you still end up with too much noise coming out.  So you either ignore it or turn it off until you need it.  

I think the value in a really good system is along the lines you pointed out, Gabe.  Two systems.  You want something really simple that doesn't require a lot of overhead, training, or resources as a quick kind of backstop.  It shouldn't complain very often unless something is really out of wack.  You also want something that can generate tremendous detail -- end to end -- and understand how all of the data points fit together.  The latter is really hard and expensive to do, and always ends up overly complicated.  In theory, being able to monitor full time can help that software figure out what changed, but in reality nobody has done that well.  But when the C-level folks call because their people can't do their jobs you really want the latter available.

As to agent overhead, far to many of these products work either agentless with WMI or with an agent that utilizes either the PDH libraries to pull information from windows.  These interfaces are horribly inneficient (especially WMI, which then uses PDH).  Those products simply need a better implementation at the client end.

That there are so many companies with monitoring products is indicative that they all are hearing that customers are not happy with what they have in place.  But the number of vendors also hurt each of them in that they cannot generate a significant enough revenue stream to fully invest in the back-end analysis part.  So they either have another product that generates revenue, get acquired, or go into another business.  Were I stupid enough to launch a product in this space today, I would concentrate on that low end system that can look at the entire server/desktop/app space and blow a horn only once in a long while.  (And for the record, I am just dense, not stupid).

Dude, I'm still laughing at the comment after Quest. That's hilarious.  In all seriousness, we do have monitoring solutions by the names Foglight and Spotlight.  vFoglight is targeted at the virtualization space and is one module/cartridge of the overall Foglight product, and is available via our Vizioncore company.  The rest of Foglight monitors just about everything one can imagine.  We're in the process of integrating vWorkspace with vFoglight, as we know it's a feature just about any customer would want.

When I said it monitors just about everything, I wasn't kidding.  The list here is pretty darn long:

www.quest.com/application-monitoring

Spotlight on the other hand is a realtime diagnostic utility set:

www.quest.com/.../overview.aspx

P.S.  I think you made a typo on number 19. Shouldn't that be "triCerat", not "tricera"?

I agree with comments put forward by Gabe, Tim and AppD.

For me in my line of work I’m basically interested in just a handful of counters and a few basic health status checks.

Depending on what I’m looking for (or working with) I adapt this basic harvest for whatever it might be is useful for me. I’d like to leave the deep probing on as-needed basis.

Then again, the world is larger than my petty stuff, so there needs to be other checks, verifications and historical trends from various key observables within the overall picture of IT.

This is all fine, if it would be so… but the gruesome reality is that the need/desire for control is flooded by oceans of incompetence by the very ones wishing to do so, which, I guess, is the reason for the endless listings of different monitoring systems.

One interesting thing that Tim pointed out on his site a while ago and also tooled (for Hyper-V) is the fact  that the game is rather different now that all things goes virtual.