[mrtg] VitalNet vs. other frontends?

Steve Shipway s.shipway at auckland.ac.nz
Tue Oct 28 00:53:15 CET 2008

> I'm aware that it *seems* like I'm comparing
> apples to oranges but I'm really not.

Ah, OK.  Now I have more details... I picked up the wrong idea from the previous email.  Now I come to think about it, I recognise your name from previous postings.

> MRTG is just a poller with no fancy front end.
> I use MRTG to poll, 14all to graph, and RRDTool to store.
> We have Big Brother tied into some rrdtool/mrtg-based graphs.
> We also wrote an alerting system to send traps from BB to
> a product we use here called Netcool.  We also send traps
> to Netcool right from MRTG, but we have some conditions where
> it requires the custom code.
> Routers and Cacti are just fancy front ends.
> Cacti can send alerts via syslog directly to Netcool.
> I don't know if routers2 can do the same.

Routers2 is just a frontend for MRTG/RRD (as is 14all), so it doesn't send alerts.  However, you can use the MRTG threshold system to trigger alerting scripts, if need be - check out the MRTG manual on the Thresh* directives.

Cacti is more than just a frontend - it does the data collection polling as well, which is why it can generate alerts.  Cacti is a bit like MRTG and Routers2 all rolled up into one.

The 14all system that you use at the moment mimics the native MRTG output.  Since you use 14all, you could install Routers2 in parallel and use either web-interface for viewing your MRTG data.  You can play with a Routers2 demo at http://www.steveshipway.org/cgi-bin/routers2.pl if you want.

> The kicker is that we already have a Cacti installation for
> our servers, but I figured it could be extended to everything
> (mainly routers and switches, but some custom OIDs as
> well) while being able to transition the old RRDs to
> Cacti and not lose any history.

You can use a Routers2/MRTG setup to do all of this sort of graphing, but if you use Cacti, you may find it easier to move to purely using that.  Cacti performs a similar function to the MRTG/RRD/Routers2 package.

> Nagios is ok, but is way overkill for the functions
> we need - trending, graphing and alerting.

You might find Nagios as a good solution after all, if you have a UNIX box to host it.  It is a great step up from Big Brother, interfaces well with MRTG (can share the same agents, Routers2 has a Nagios plug-in to embed pages, and you can put Routers2 or 14all links into the Nagios definitions).  It is relatively simple to set up and you don't need to use all the features if you don't want to.

> We have over 3,500 routers and switches being graphed
> by the MRTG/RRDTool/14all/BB solution.  At last count,
> it was about 18k different metrics (in, out, cpu, temp,
> drops, etc.) for the targets.

This seems a pretty large setup to me.  I'd say a Nagios/MRTG/RRDtool solution wouldn't be overkill...  You've slightly more metrics than we're graphing with our setup.  However if you only need alert generation, and not alert management, then Nagios may be too much.

> Nagios is ok, but it's a toy compared to Netcool.
> To be fair, so is BB, and Hobbit, and ZenOSS,
> and some of the others I know of.

If you have all the necessary licenses for Netcool, probably you need neither Nagios nor Big Brother.  Provided you have a scriptable way to send downstream alerts to Netcool from a MRTG threshold script, you seem not to need any other alerting system.

> I just need to come up with a reason to continue
> with a FOSS trending and graphing solution, rather than
> a closed solution with seemingly the same (or less)
> technical functionality.

The reason that always works here is 'It's free'.  To be honest, I'd rather go for a fully-provisioned Tivoli or whatever setup, but given the budget Nagios/MRTG is a good solution for us.

We're a bit at risk of going off-topic for the list here as we're talking Nagios and Cacti; however we mentioned 14all and Routers2 so we've not diverged too far yet :)

Hope this is more helpful...


More information about the mrtg mailing list