[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