Funny ... I am just sitting here configuring Nagios, and marveling at how much power there is in an object oriented template system and wondering why it isn't used more ...
Adam's xkcd comic had me laughing when it was first posted, now it has me cringing. Tom's mention of the four ponies of the monitoring apocalypse are a great starting point. So ... what is going to be different than Zenoss, MRTG, Nagios, MS-SCOM, HP Openview, etc.? I've used them all ... and the only one I complained about was MS-SCOM (although it DID have a few nice features). The monitoring market has high table stakes. What are you going to do that can't be implemented by a large organization that already has a monitoring product? On Fri, Jul 22, 2011 at 3:58 PM, Paul Graydon <[email protected]>wrote: > On 07/22/2011 09:16 AM, Robert Hajime Lanning wrote: > >> On 07/22/11 09:44, Paul Graydon wrote: >> >>> On 7/22/2011 2:29 AM, Adam Moskowitz wrote: >>> >>>> Paul Graydon wrote: >>>> >>>>> Hopefully with a good wide spread of interest and talents we could >>>>> finally get a monitoring tool that doesn't actually suck! >>>>> >>>> And what color pony do you want with that? >>>> >>>> Seriously, given the incredibly wide range of applications, situations, >>>> SLAs, services, constraints, conditions, and requirements, I think the >>>> idea that a single tool will solve everyone's problems is, well, nothing >>>> short of ludicrous. >>>> >>> By making /everything/ modular and extensible, and having the monitoring >>> platform be a framework which individual components are natively plugged >>> in to, everything from data collection, to presentation, reporting or >>> responding . That's what the proposal seems to boil down to. It's >>> something we're sadly lacking with most monitoring solutions that I've >>> ever seen. It's almost entirely 'their way or the high way', with a few >>> bolt-ons on the side, fudged into place just to get by (with all the >>> unreliability and risk that implies) >>> >> Then you end up with HP OpenView... >> ugh >> > So help them make it not HP OpenView. Point out the mistakes made with > that platform, what it's good at and what it's bad at. They're at the very > initial design stages, not implementation and so now is the time to help > ensure what they produce goes the right way. > > It's rare to get a chance to influence a product in these stages, usually > by the time people start really talking the initial implementation is > already done (along with what may be bad design decisions.) Most of these > solutions come out of something coded to meet a businesses specific needs, > not a bunch of people across a number of different businesses and > environments collaborating. > > What we've got here are a bunch of dedicated and talented programmers and > operations people motivated to solve a real problem, and not only willing > but enthusiastic about spending their spare time on it. We'd be utter fools > not to capitalise on that. We can either sit here and moan about how bad an > idea this is and 3 years down the line be proven correct as yet another > product fails to meet the real operations needs, or participate and help to > make something that makes a serious attempt to fix a very real and > significant problem, and maybe, just maybe, 3 years down the line find > you've got something of use. > > Paul > > ______________________________**_________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-**bin/mailman/listinfo/discuss<https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss> > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
