[rrd-developers] Update ex post?

[Sebastian Harl]

Hi Till,

On Wed, Aug 25, 2010 at 07:49:12PM +0200, Till Dörges wrote:
> On 24.08.2010 12:44, Sebastian Harl wrote:
> > What other real-world use-cases, other than removing spikes or undefined
> > values, are out there? Those are the only ones I've encountered so far.

> For our particular scenario we can even limit the time window for which we'll accept
> an update ex post.
> 
> With that particular constraint the most favorite solution right now looks like a
> combination of a normal RRDtool db and a MySQL db. The former works as always, except
> that it doesn't store updates until t_now but until t_now - t_window. t_window is the
> time window for which we'll accept updates ex post. All the data between t_now -
> t_window and t_now ends up in MySQL. If any late updates arrive putting them in MySQL
> shouldn't be a problem.
[…]
> The downsides I can see is that an additional db adds extra complexity. And you have
> a bit of effort to put into transferring the data.

That sounds like a rather special use-case to me but which adds quite
some complexity and which does not seem (on a first glance) to solve the
actual problem: modifying existing old CDPs, which would have to be done
when transferring the SQL data back to the RRD.

As a more general solution, it might make sense to provide a feature to
replace a whole range of data in one go. That would allow to update some
CDPs with rather exact data and leave interpolation (or whatever might
be done) to one CDPs at each side of the specified time slot. Storing
that data would then be left to the user but could be supported by
RRDtool by providing means to read the data from several data-sources
(SQL db, CSV text file, …).

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20100826/6e16f7d0/attachment.pgp