[rrd-users] Re: Getting the timestamp corresponding to MAX value

[Tobias Oetiker]

Hi Kevin,

> First, storing the events alongside is not a problem, although I'm not
> exactly sure how to incorporate that data using VRULEs when using drraw,
> cricket, or cacti.

well that would mean enhancing these tools ...

> Furthermore, while storing this data flatly doesn't
> inherit much development overhead, tracking peak range values then
> becomes a task, almost duplicating some of the functionality of the rrdb
> already. For example, we'll have to write code to handle rules of value
> ranges and conditions. Clearly not an issue for a few things to monitor,
> but when you monitor hundreds or thousands of services, this could get
> fairly intense.

hmm I guess you lost me here ... what is it exactly you want to
monitor ? if you have hundreds or thousands of services then I can
not see how an individual event would be relevant as such other
than in a statiscial manner and even there classification may
become an issue ... I guess you have to be more specific ...

> Second, the smoothing issue is fairly confusing for us, because we have
> many scenarios where we don't need or want smoothing, but would just
> prefer that particular value to fill the corresponding timeslot. For
> example, if I am monitoring an object that can only have 4 values, 0, 1,
> 2, and 3, I never want to see 0.2 or 1.6.

an example you have a modem bank ... with 4 modems ... at any point
in time there are exactly 1,2,3 or 4 modems in use ... so how somes
rrdtool will store 3.5 or some other odd number ....

the timeslots always contain the average value valid for the
periode of the timeslot ... so if you had a timeslot of 1 hour, and
for 40 minutes 4 modems were in use and for 20 minutes 2 modesm
were in use, what would you store in the 60 minute timeslot ?

  (4*40+2*20)/60 = 3.3333

surely someone will one day ask you how it could be that 0.3333
modems were in use that hour ... that is the smoothing for you ...
it is right thoug ... but maybe i miss something ... again if you
make an example this may clear things up ...

> than sufficient. Further, so let's say our step was supposed to be at
> time X but we actually updated it at X+32secs, store whatever the value
> was for X, rather than try to determine what it COULD have been at that
> time. We are all a little confused why this functionality couldnt
> coexist!

if you want your value to go in a X then you can specify X as the
time for the value when you update, no problem ... for the rest see
my example above ... just this, because some people felt that the 1
second resulution rrdtool originally used to take its reading was
causing too much jitter, they added subsecond resolution.

hope this helps
tobi


-- 
ETH Zurich
Tobias Oetiker, IT Support Group D-ITET (ISG.EE)
ETL F24.2, Physikstrasse 3, 8092 Zurich, Switzerland
Phone +41 44 63 25286,  http://people.ee.ethz.ch/oetiker/

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi