[rrd-users] Input values normalization
Donovan Baarda
abo at minkirri.apana.org.au
Mon Feb 24 00:20:40 CET 2014
On 22 February 2014 03:49, ENTRESSANGLE, ERIC (ERIC) <
eric.entressangle at alcatel-lucent.com> wrote:
[...]
> Each minute based on the full minute (i.e 18:23:00, 18:24:00), the
measuring device writes the counter value in a file. Then the measuring
device resets the counter value to 0. So the counter value at 18:24:00 is
the number of opened sessions between 18:23:00 and 18:24:00. And in our
case, the 9 sessions are created between 18:23:00 and 18:24:00.
Ah. In that case what your measurements already have a timestamp associated
with them. For accuracy, you should use that timestamp (18:24:00 in this
case).
> But cacti's poller retrieves the counter value from the file at 18:24:15
(because we put a tempo to be sure the whole file is written, and anyway
there are a lot of counters to retrieve, so the polling will never occur
exactly at 18:24:00). So the rrdtool update timestamp is 18:24:15, whereas
in fact the timestamp should be 18:24:00, because it is the counter value
at 18:24:00 which is retrieved.
rrd allows you to specify the timestamp to use for updates which for your
case you could do like this;
rrdtool update my.rrd $[ `date +%s` / 60 * 60 ]:v1:v2:...
Though probably using the timestamp of the file would be more accurate
since you could occasionally somehow have missed updates;
rrdtool update my.rrd $[ `stat -c "%Y" /my/infile` / 60 * 60 ]:v1:v2:...
I don't know cacti, so I don't know if it allows you to specify the
timestamp, or how to do it.
Is there some raw session counter you could read directly instead of this
counter file approach? Alternatively you could have your measuring device
directly update rrd at each session, which would be the most accurate way
to do it. rrd can probably do a better job of normalizing this data into
sessions/minute than your measuring device.
--
Donovan Baarda <abo at minkirri.apana.org.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20140224/0479ec55/attachment.htm
More information about the rrd-users
mailing list