Thanks to all posters both on and off list. It's gratifying in some way to find 
that nobody's found a better solution than Tobias did all those years ago.

After trying loads of these options out, I found that, on a general level, 
their packaging stinks! If I can't get the sodding things to work after an hour 
of farting around, then out the door they went.

Many thanks to Craig, who's offlist help was extremely useful.

In the end, I've gone with munin, and am in the process of extending it heavily 
to support my own weird requirements. It has been really useful already in 
identifying knock on effects of varions maintenance processes - always a real 
pain - and also software I've forgotten to uninstall, like portsentry on one of 
my servers. Oops.

I'll leave it for a week or two then start setting up thresholds so my servers 
can better tell me when they're ill, instead of my having to keep asking them 
all those impertinent questions!

Cheers,

Steve

On Thu, 02 Aug 2007 10:26:11 +1200
Jim Cheetham <[EMAIL PROTECTED]> wrote:

> These are the back-end tools. You'll find many products for managing
> sizeable infrastructures build on these.
> 
> I like Munin, but have my suspicions about the load it induces -
> perhaps it needs to be run nice.
> Cacti is quite network-equipment focused.
> Nagios is nicely service-oriented, and there's a plugin to store
> long-term data into cacti IIRC
> Statscout is used by one of my customers, for network stuff
> 
> If all you need is server load and a couple of custom things, on a
> small population of servers, you're probably well advised to stick
> with RRD datastores and MRTG to present them.
> 
> If you need a more detailed application-level health, use Nagios to
> look in from the outside, and consider the
> free-as-in-beer-as-long-as-you're-only-having-one Splunk to get access
> to your logging data. Otherwise just logcheck to get the exceptions.
> 
> -jim
> 
> On 02/08/07, Steve Holdoway <[EMAIL PROTECTED]> wrote:
> > Does anyone know of anything better than these tools to monitor server 
> > loads and the like? Not that I'm denigrating Tobias's work in any way, it's 
> > just that I've been using these for 10 years or so, and may have missed out 
> > on something newer!
> >
> > Cheers, Steve
> >
> >

Reply via email to