[rrd-users] Re: MRTG/14all ideas! Parser module and "Perl Code Targets"
Rainer Bawidamann
Rainer.Bawidamann at rz.uni-ulm.de
Wed Jun 28 15:21:31 MEST 2000
In article <3958A085.E78D1D89 at oracle.com>,
jakob.ilves at oracle.com (Jakob Ilves) writes:
>
>> I think it wouldn't take much time (for me). I would take the parser out
>> of mrtg and add some calls to log2rrd. Maybe I'll do it because it's
>> good for 14all ;-)
>
> It would be VERY good for the MRTG and 14all community, especially if
> you isolate the MRTG-config parser into a independent Perl module. That
> way, you could let MRTG, 14all, log2rrd and other utilities use the SAME
> code for interpreting the config file. Once you've created the Perl
> module, submit it to Tobi so he can review it. If it's good enough he
> will most likely use that Perl module for future MRTG releases.
I don't think that the config parser of mrtg is worth to make a perl
module from it (sorry Tobi). In fact I don't think the config
language is worth preserving :-{
> Ideally, the code should accept a file name and return a reference to a
> (big) data structure with the contents of the MRTG config file. This
> way you could actually parse several MRTG files and have several data
> structures as a result.
I think it would be better to have an object oriented approach. I.e. you
have an object which holds the information and an API to access it.
Something like
get_target_list()
get_target_option(target,option)
...
This way an application does not depend on the config language. You
could replace the config module to support another one.
With multiple objects you can access mutliple config files.
> (volunteers could read your modules code and then write the docs)
Do you have some "volunteers"? I would have some code ... ;-)
> Such documentation could make it possible to implement an enhancement
> for MRTG: "Perl Code Targets"! That is, when MRTG "polls" the "Perl
> Code Target", a snippet of Perl code is run in a strictly defined run
> time environment with all the MRTG data structures available.
I don't want to tell an administrator that he has to learn perl to
configure a statistics software. mrtg with 14all does only the data
gathering. If you know perl and want to write "perl code targets" you
should know how to write the rest of a data gatherer: Just use snmpget
and rrdtool. You can use a mrtg.cfg and 14all to display the data.
In fact your example is possible with my thesis program "togather"
without any "perl code targets". I will have a version that works with
stock rrdtool soon (as I found the error with RRDs::info) for anybody to
try.
> The case I use as an example above solves the problem that even if you
> get more than two metrics from a poll, you can only collect two metrix
> in a single MRTG target. This is of course possible to work around by
> doing multiple polls but it's better to just do one poll and get every
> metric, especially as a poll means sending 10 ping packets.
One of the limitations of mrtg.
> What my app does? Well, it provides you with a screen containing of a
> large number of "strips", two per MRTG collection. The strips are
> actually 10 pixel high RRD graphs which are green under ideal conditions
> but shows red parts whenever the MRTG collection violates a specified
> threshold in any direction. This way you get an index of your MRTG
> collections and the index is very high density.
Examples online?
Rainer
More information about the rrd-users
mailing list