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

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


More information about the rrd-users mailing list