[mrtg] Re: Proposal: "Passive" or "Serverized" MRTG. (Instead of collecting it passively waits for data to arrive).

[Bjorn Nordbo]

Jakob Ilves wrote:
> Hello MRTG community!
> 
> Currently all data collection done by MRTG is scheduled by MRTG itself.
> This works great in many circumstances, where the SNMP polling or the
> external script doesn't take too long time.

Your points are quite valid, and I have at least two applications
that doesn't conform to the standard run,poll model of MRTG:

- Bulkstats on Unisphere ERXes. The router can be configures to send
  a predefined set of data by FTP every n minutes. To use these data
  with MRTG I have a daemon that checks the dump directory every 10
  seconds. If it finds any new files there, it parses it, writes a
  intermi interim file to another directory and deletes the dump file.
  When MRTG is scheduled (by crond) it will gather data through a
  script that will read the interim file. The format of the interim
  file is <router>:<isdnports>:<pstnports>:<xdslusers>. This works
  great and allows for a lot of flexibility for grouping data (ie.
  ports per pop, hunt group or router) without increasing the number
  of polls.

- SAA-measurements. I am working on this now, and as far as I can
  see this is next to impossible to do with MRTG without loosing
  just about all of the flexibility of SAA. I'll either have to
  gather a lot of data every hour (and MRTG only supports one set
  of datapoints per run) or collect data every five minutes and
  clear the SAA collection tables after every run (extremely in-
  efficient).

Both of these measurements would be better off if MRTG were a server
able to respond to external events instead of assuming that every-
thing was the same each run.

Other problems with MRTG are the two-datapoints-limit, the lack of
a general overview of polls (if you want to poll the same OID three
times, once for ports in use per router, once for hunt group and one
for pop, you will end up with three polls when one poll would have
done the same job).

Retrofitting MRTG with these features may be quite hard, and in the
end I suppose we'll end up with Concord Network Healdh or something
like that.

Anyone knows anything about what plans exists for MRTG 3.0?

-- 
Bjørn Nordbø  -  IP Development  -  Nextra Norway

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