[mrtg] Best Practice Questions
Barakat, Mehmet-Hasan
hbarakat at kpmg.com
Sun Nov 16 16:02:54 MET 2003
The addictive nature of monitoring has presented me with a procedural
dilemma, and I'd like some input.
I'm monitoring servers, switches, routers and smart-PDUs for processor
utilization, memory, storage, traffic, errors, temperature, humidity, power
draw and more.
My mrtg web directory is starting to get cluttered. Before this bludgeons
totally out of control, I must bring some organization into the mix.
Background - RH9 running RRD tool with routers.cgi. Love it.
* I'm adding each .cfg file to my /etc/crontab as I build a config. I bet
there's a better way of doing this.
* I'm wondering whether it's better to use a big config file with many
targets or many little config files.
* What's an accepted way of hierarchy? Like - should I do a cfg for all my
routers monitoring for CPU and another cfg for memory? Or should I have each
router at the top, with sub-targets within each cfg for memory, util,
traffic, etc? Or should I have one big huge massive cfg that has all my
campus nodes? Is there a boost to performance going one way over the other?
Thanks
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************
--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive http://www.ee.ethz.ch/~slist/mrtg
FAQ http://faq.mrtg.org Homepage http://www.mrtg.org
WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
More information about the mrtg
mailing list