Hi Till,
this will not create corect results, since in GAUGE, rrdtool
assumes that for every update the value of the GAUGE datasource has
been at the new value since the last update.
so if your updates are at irregular intervals, the updates after
long intervals wil have undue weight
also how would you handle the case when 2 updates arrive in one
second ?
cheers
tobi
Today Till Dörges wrote:
> Hello everybody,
>
> thanks for all the answers. :-)
>
> On 25.03.2009 09:27, Karl Fischer wrote:
> > Till Dörges wrote:
>
> >> I'm trying to collect and store data (e.g. how many times a TCP port is
> >> being
> >> accessed in a certain interval) but with a rather unpredictable source.
> >> Ideally I get
> >> a measurement every 300 seconds. But sometimes I don't get anything for
> >> hours or
> >> days. I intend to store the data for 7 days in the original resolution
> >> (300s).
> >>
> >> For performance reasons, 'rrdtool update' should only be called, when
> >> there actually
> >> is data. This means for the example below, it's called only 5 times.
> [...]
> > well, as Simon and Darren said already, rrdtool is not really designed for
> > that.
> > However, you can get around this by changing your heartbeat to a week and
> > insert
> > just one zero at N-300 if there hasn't been an update at N-300, so you need
> > to
> > remember the last update or to query the rrdb:
>
> I was thinking into that direction, too. After meditating over the problem
> for a
> while I tried inserting 1 additional values for every original value. Exactly
> one 1
> second before the original:
>
> --- snip ---
> rrdtool create test.rrd --start=1237923899 DS:events:GAUGE:600:0:U
> RRA:AVERAGE:0.5:1:2016
> rrdtool update test.rrd '1237923899:123'
> rrdtool update test.rrd '1237923900:123'
> rrdtool update test.rrd '1237924199:456'
> rrdtool update test.rrd '1237924200:456'
> rrdtool update test.rrd '1237924499:789'
> rrdtool update test.rrd '1237924500:789'
> rrdtool update test.rrd '1237931699:1111'
> rrdtool update test.rrd '1237931700:1111'
> rrdtool update test.rrd '1237938899:2222'
> rrdtool update test.rrd '1237938900:2222'
> --- snap ---
>
> Which also seems to give me what I want:
>
> --- snip ---
> <!-- 2009-03-24 20:45:00 CET / 1237923900 --> <row><v> 1.2300000000e+02
> </v></row>
> <!-- 2009-03-24 20:50:00 CET / 1237924200 --> <row><v> 4.5489000000e+02
> </v></row>
> <!-- 2009-03-24 20:55:00 CET / 1237924500 --> <row><v> 7.8789000000e+02
> </v></row>
> <!-- 2009-03-24 22:55:00 CET / 1237931700 --> <row><v> 1.1110000000e+03
> </v></row>
> <!-- 2009-03-25 00:55:00 CET / 1237938900 --> <row><v> 2.2220000000e+03
> </v></row>
> --- snap ---
>
> Looking at the documentation this approach shouldn't have any side effects.
> I'm
> interested in the primary data points and they seem to come out just right in
> the RRA.
>
> Are there any problems with this approach?
>
> The downside, however, is that I double the amounts of writes to an RRD. OTOH
> with
> the other solutions suggested I'd have to do a query on the RRD. W/o having
> measured
> anything my guess would be that there is not much difference.
>
> Also this approach has another benefit for me. The RRDs are usually queried
> up to the
> last update step. For the above example 1237938900. Without the update at
> 1237938900-1 I don't have an entry in the RRA at 1237938900.
>
> Regards -- Till
>
--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900
_______________________________________________
rrd-users mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
