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

[Jakob Ilves]

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.

However, I've encountered situations where the data gathering cannot be
initiated by MRTG, instead, external sources (such as scripts running
elsewhere) schedules the data collection.  What I would like to see is
that MRTG somehow accept to stay "passive" and let the external sources
contact it and tell it "Ok, this target now got these two values".
Essentially, this means that the MRTG collection starts to run as a
server to be contacted by external sources which specify one or more
targets to write data to.

For instance this situation can occur in a firewall environment where
MRTG isn't allowed to initiate any communication with the machines on
the other side but where the other side's machines are allowed to
initiate contact with the MRTG server.  Another situation when this
would be handy is when the data being collected takes a while to
produce, perhaps a few minutes.  In those circumstances, you don't want
MRTG to go out and run that script and be halted for those minutes.
Instead, you want the script to run on it's own and let it decide when
to provide the data to MRTG.

Any ideas on how to design this beautiful beast?  One way is to let an
external script do a remote shell and fire up MRTG with some command
lines like cfg-file, target name and values which makes MRTG wake up,
parce the config, identify the target and write down the data and then
exit.  After some time, the external script decides it has gathered some
new data and do a remote invoke of MRTG.

The problem with that approach is that it takes quite some resources to
fire up MRTG and read the config, especially if the config file is
large.  If this has to be done once for every target in the config, the
"passive" MRTG takes much more CPU than the "normal" MRTG which reads
the config once, polls all targets at once and then exits.  Of course,
the "passive" MRTG could be invoked to not only write data for one
single target but for multiple targets but still, you face the situation
where each external source only has data available for one single target
at a time and you perhaps has hundreds of such targets, each on it's own
host...

Another approach is to "Daemonize" or rather "Serverize" MRTG.  You tell
it in the config that it should go "passive" and accept updates on a
specific port.  Then the external scripts use that port to write the
data. Of course, this would require some elaboration not only in writing
the MRTG program but it might require some wrapper utility on the remote
script side which can be used to "push" one or more targets' values into
the MRTG process.

You can also make the "Serverized" MRTG use a UNIX socked, that is, a
file system socket or named pipe.  Once that is done you can let a
remote machine do "remote shell" to the MRTG host and then run a nice
wrapper script which will write the data to the pipe.

Another approach for this Server MRTG is to have a dispatcher process
for MRTG which listens on one port for update requests and then for each
request, writes the data to the right pipe (where each MRTG server is
running and listening to it's named pipe).  This approach do of course
require each request to include not only targets and values but also the
location of the pipe (or perhaps just which config file...).

What do you think about it?

Best regards

/IlvJa

--
                (Jakob Ilves) <jakob.ilves at oracle.com>
             {Oracle Global IT, Network Management Group}
[Office as well as mobile phone: +46/8/477 3666 | Fax: +46/8/477 3572]



-- Attached file removed by Listar and put at URL below --
-- Type: text/x-vcard
-- Desc: Card for Jakob Ilves
-- Size: 444 bytes
-- URL : http://www.ee.ethz.ch/~slist/pantomime/26-jakob.ilves.vcf


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