[collectd] collectd + YaketyStats

[Florian Forster]

Hi Mark,

On Thu, Jan 22, 2009 at 10:50:00AM -0500, Mark Plaksin wrote:
> OK, I'm sold.  I'll look at changing YaketyStats to include all three
> and at a script to convert existing YS RRDs to have all three.

in collectd's contrib/ directory is a script called `rrd_filter.px'
which can do that. Run
  $ perldoc contrib/rrd_filter.px
to access the built-in documentation.

> I like that graph.  Graphing all three works nicely if you have just
> one stat on a graph.  If you have more than one stat and graph all
> three CFs it's hard to tell what's going on.

Right, with one value it works nicely. For `load' graphs, I usually only
graph that minimum/maximum area for the 1-minute average. Other than
that, I haven't gone through the trouble to write something to make two
partially overlapping see-through-kinda areas you'd get when two data
sources are involved. Let alone having this for n >= 3 values.

> > I think splitting the IO-stats up into two data sets / RRD files
> > doesn't make much sense - IO, as the name implies, will always
> > consist of input and output, so putting those two into one file is
> > the reasonable thing to do.
> 
> It *is* reasonable but would you lose anything (other than the pain of
> conversion) by splitting them up?  It is definitely possible to code
> around having multiple DSes in each RRD file.  And it's possible to
> discover the DS name(s) in each RRD file.  But it's easier and cleaner
> if you don't have to do that.

Yes, it would technically be possible to split up all files so each one
has only one DS. You would be able to store the same data afterwards and
would hardly lose any data while converting the files.

I do see that having just one DS per file and having all DSes have the
same name makes graphing a big deal easier. However, changing the layout
of data in collectd plugins would be a backwards incompatible change.
Making backwards incompatible changes every now and then is important to
keep stuff elegant and clean, but right now there aren't enough problems
in collectd that would be solved by such a dramatic step to justify it.

> For example, it seems like there are two choices for determining DS
> names.  One way is to look in each RRD file as you get to it.  If you
> have a lot of graphs to draw (say you click on "[All]" for a certain
> host name in Jart, or a playlist that graphs the rx_bits for all hosts at
> one of your sites) that's a lot of extra 'rrdtool info' commands.

I think the most elegant solution to this is to consider the DS name
part of the overall name of the data. Where previously you used `$FILE'
(and actually meant `the "value" DS of the file $FILE'), you could use
`($FILE [, $DS])' to mean `the $DS DS of the file $FILE'.

This way the DSes of an RRD file need to be looked up when scanning for
new/available files to build a new graph, but not when displaying a
``playlist'' or pre-created graph. Kind of `caching in the graph name'.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090123/5a4f0e1f/attachment.pgp