[rrd-users] Splitting database and graphing functionality

Sven-Göran Bergh svengbergh-rrdtool at yahoo.com
Thu May 31 22:41:16 CEST 2012


>Från: "Duncan.Innes at virginmoney.com" <Duncan.Innes at virginmoney.com>
>Till: rrd-users at lists.oetiker.ch 
>Skickat: torsdag, 31 maj 2012 11:11
>Ämne: [rrd-users] Splitting database and graphing functionality
>I've been using rrdtool for a number
of years now, but have recently had it come under the spotlight from our
IT Security team. 
>As a bank, we have a strong lean towards
reducing the number of installed packages to reduce the possible attack
surface for any potential issues. 
>To this end, I have been asked why we
need to be installing a bunch of graphics, font and rendering packages
on all our servers when all we're looking to do is record data in RRD's
most of the time. 
>Is it possible/feasible to split the
database and rendering functions of rrdtool into separate packages?  For
example a base rrdtool package containing just RRD management functionality
and a modular rrdtool-graph containing the rendering & graphing functions.
 This would allow security conscious users to deploy the base rrdtool
package to record data across an estate of machines and then install the
extra rrdtool-graph package on a central machine to handle the graph rendering. 
>Does this sound realistic?  Achievable?

Interesting! we have the same problem, but from an embedded POV.
The system only do rrdtool create/update. No graphing, no CGI,
etc. so the additional bloat is a concern for us. It goes without
saying that Perl is a no-no as well.

There is a compilation target in the source called rrdupdate
without any external dependencies that looks promising.
However, we still need a replacement for "rrdtool create".

Such a replacement without external dependencies together with
rrdupdate  would be the solution for both of us.

Hopefully the list wizards might be able to spread some light
on this.


More information about the rrd-users mailing list