[mrtg] MRTG and the "early data gathering" phenomenon (problem?) (fwd)

[Peter Stamfest]

Hi everybody, 

I sent the message included below to the comp.dcom.net-management
newsgroup, but didn't see any reactions. So I thought I might try it here.

If I talk nonsense, or misinterpret somethin, pls tell me as well.

peter




---------- Forwarded message ----------
Date: Tue, 26 Sep 2000 08:18:16 +0200
From: Peter Stamfest <peter at peter.stamf.pr.at>
Newsgroups: comp.dcom.net-management
Subject: MRTG and the "early data gathering" phenomenon (problem?)


Hello everybody, 

I'm currently implementing MRTG for a large number of interfaces (several
hundered, potentially thousands). I plan to use MRTG with the UseRRDTool
and RunAsDaemon options. 

There is no problem with RRD and MRTG itself, but with the restarting of
the daemon upon a configuration change (something that will probably
happen quite often). There will be a number of mrtg processes running in
parallel to gather the data.

Now for the interesting part: When looking at the code of mrtg, I found
that there seem to be no provisions against "early data gathering". 

What I mean by this is that if I stop and start the mrtg daemon(s), they
will start to fetch SNMP data as soon as they start again. This is up to 5
minutes (in the default setting) to early (In average it will be 2.5
minutes, obviously). I think that this can (in the case of many
restarts) lead to strange results in the produced graphs. I guess it
might look like a positive or negative spike.

Are there any plans to correct for this, or has anybody seen this problem
before? Or an I totally wrong?

Some possible solutions:

1. One idea is to have some "mrtg restarter" in cron (where mrtg used to
sit) that checks at 5 minutes intervals if mrtg has to be restarted or
not, but this also leads to problems if there has to be no restarting for
a while, as the two independent cycles (mrtg and cron) might get out of
sync [although mrtg tries to defend against it, as far as I can see from
the code].

2. Another possibility would be to restart mrtg at most once a day, and to
define that "interface changes will only be  effective from tomorrow".

3. A third possibility would be to put some restart logic into mrtg, that
restarts mrtg when the configuration file changes (just doing a "exec
mrtg ... " should suffice I guess, but I didn't think about it too much
yet).

I think the most stable solution would be 2., the most comfortable
solution is 3., but one has to defend against configuration file syntax
errors.


Any opinions on this issue? If the mrtg "core team" wishes, I might look
at solution 3 and contribute patches for it. I might add that the whole
system, along with its database, admin and customers web interface will be
operational within 3-4 weeks with testing beginning immediately, so this
is rather urgent for me, so I will eventually do something about it, but I
wanted to check for other opinions first. 

peter 

-- 
Peter Stamfest                    UNIX, Networking & Computing Consultant
Tel: +43/699/20711205             Software Development
E-Mail: ps at psncc.at               WWW: http://www.psncc.at/
        peter.stamfest at eunet.at 





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