[mrtg] Re: RE : Re: Problem with indexmaker ! I use MRTG and RRDtool databases - Isit a bug ?

[Peter Glanville]

>> Indexmaker won't work, as it generates a page of HTML including graphs
>> (and linking to pages) produced by MRTG in non-RRD mode.
>> Since you use RRD you're out of luck there.
>>
>> Option 1. Use 14all*DontShowIndexGraphs

>I don't know how to use this option.  I try to add a line in the
>beginning of my mrtg.cfg file :
>UserRRTool[_]:14all*DontShowIndexGraph[]

No, you can just put "14all*DontShowIndexGraph[_]: 1" at the top, or (I
presume) at each Target level.
It depends how you want to use it. See my description at the end.

>> Option 2. Do not point the CGI at the live CFG file, but create a
>> number of
>> dummy CFG files that the CGI points to, each having a smaller,
>> acceptable number of graphs in it.

>Do you mean I should create a cgi per config file (one config file per
>router). It should be very long and not so flexible. Because, I already
>have  40 routers to manage. So I should create 40 cgi and realize one
>HTML page with the links to the corresponding cgi. I prefer to use
>Option1, can you help me, please ?

See my description at the end for CFG creation.
For linking the CGI to the cfgs, 14all seems to work in a number of ways.
You can rename the CGI to match the cfg, or hard code inside the cgi which
cfg it refers to, or you can specify in the browser (or link) which cfg to
read.
RTFM for what line in the CGI to edit, to get it to perform each option.

>> Option 3. Get the manglement to buy you more processing power

>what does mean "manglement" ? I don't understand this word. Can you
>explain me more, please ?

Sorry, I was being rude about 'management', who normally expect you to
produce wonderful results without being prepared to fund the appropriate
resources. They tend to mangle any good idea.

>> Option 4. In the Unix world, I hear of tools called FastCGI and
>> SpeedyCGI that help (I'm stuck with Win-doze)

>Yes, I heard about it, but I didn't investigate so much my time to see
>what it does. A priori, it is used to accelerate cgi, but it is maybe
>not advise to use it with 14all-1.1cgi, if I remember well what I have
>read in the documentation

I wrote directly to Rainer about 14all, and (in his reply) he suggested
speedyCGI, so it must work!



OK, How do I use it?
I have one massive mrtg.cfg running with RRD, creating databases. (Routers,
ethernet switches, etc).
I have then taken the mrtg.cfg, containing hundreds of Targets, and split
it into a number of separate files, splitting in a meaningful manner (eg
one with routers, one with all the ports on the switches in a single
building, one with various Dial-up options and so on).
I have a dummy page of HTML that I have created (a diagram of the Company)
with a number of hyperlinks.
Each link invokes http://server/path/14all.cgi?cfg=filename.cfg where the
filename points to the appropriate cut-down cfg which contains relevent
Targets.
The obvious downside is that when I add another building, I need to not
only update mrtg.cfg, but also any related cut down cfgs. And some links
might appear in a number of places (and therefore cfgs)
Then from my master page, I select a link, and get an index of the daily
graphs for a meaningful group. Clicking on one of those will allow drilling
down to detail on one Target.

OK, I could have created one cgi for each cfg, and made simpler links, but
that's your choice.

Using DontShowIndexGraph suppresses the index page daily graphs.
It would give you an HTML page with a list of Targets, but no ability to
cross refer them. I like to see an overview. For example: I can see, at a
glance, if one router is putting excessive traffic onto the Wide Area
Network, which other Router is receiving it. Easy traffic monitoring,
rather than just measuring bandwidth utilisation.

Too many targets in one cfg takes the CGI ages to load up (if displaying
the index graphs). More processing power in the webserver (or SpeedyCGI?)
is the only cure.
I have been running on w2kPro (Intel pIII 450) for some time, and limit it
to 70 graphs (ie Targets) per page as an absolute max, but just a dozen is
time consuming to view.
This limits what else I monitor. I am reluctant to look at the 96port patch
cabinet switches, and stick to the ethernet backbone and server farm ones
at present.
I have tested multi-processor, and it worked well, about 75% more index
graphs per minute on the cgi page. Currently asking the management for
money to buy a new box, with two fast processors. We have no Unix
experience, so I cannot compare the two in ability.

Regards
Peter


--
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