Re: Using Maximum values to avoid spikes?

Wow... I must have written that about 13 years ago.

I'm pretty sure it's all still 100% correct, but I think things like
DCOUNTER didn't exist then, so there might be other things worth
investigating now.

On 21 August 2015 at 04:38, Robert C. Seiwert <[email protected]> wrote:

> Of course looking at the docs I could be wrong
> "Internally, derive works exactly like COUNTER but without overflow
> checks. So if your counter does not reset at 32 or 64 bit you might want to
> use DERIVE and combine it with a MIN value of 0."
> "NOTE on COUNTER vs DERIVE
>
> by Don Baarda <[email protected]>
>
> If you cannot tolerate ever mistaking the occasional counter reset for a
> legitimate counter wrap, and would prefer "Unknowns" for all legitimate
> counter wraps and resets, always use DERIVE with min=0. Otherwise, using
> COUNTER with a suitable max will return correct values for all legitimate
> counter wraps, mark some counter resets as "Unknown", but can mistake some
> counter resets for a legitimate counter wrap.
>
> For a 5 minute step and 32-bit counter, the probability of mistaking a
> counter reset for a legitimate wrap is arguably about 0.8% per 1Mbps of
> maximum bandwidth. Note that this equates to 80% for 100Mbps interfaces, so
> for high bandwidth interfaces and a 32bit counter, DERIVE with min=0 is
> probably preferable. If you are using a 64bit counter, just about any max
> setting will eliminate the possibility of mistaking a reset for a counter
> wrap."
>
>
> -----Original Message-----
> From: rrd-users [mailto:rrd-users-bounces+rob=
> [email protected]] On Behalf Of Robert C. Seiwert
> Sent: Thursday, August 20, 2015 2:35 PM
> To: 'Florio, Christopher N' <[email protected]>;
> [email protected]
> Subject: [GRAYMAIL] Re: [rrd-users] Using Maximum values to avoid spikes?
>
> The problem I think is that COUNTER only detects a reset at the 32bit or
> 64bit border.
>
> I think that DERIVE would give you a negative spike. You might try
> DCOUNTER. This is floating point which I know is not ideal for the
> application. The only substantial difference to COUNTER is that DCOUNTER
> can either be upward counting or downward counting, but not both at the
> same time. The current direction is detected automatically on the second
> non-undefined counter update and any further change in the direction is
> considered a reset. The new direction is determined and locked in by the
> second update after reset and its difference to the value at reset.
>
> BTW,  Nice garden!
>
> -----Original Message-----
> From: rrd-users [mailto:rrd-users-bounces+rob=
> [email protected]] On Behalf Of Florio, Christopher N
> Sent: Thursday, August 20, 2015 2:20 PM
> To: [email protected]
> Subject: [GRAYMAIL] [rrd-users] Using Maximum values to avoid spikes?
>
> Hey all,
>
> I've got a home brew rrd file that I've made to keep track of ISC bind
> statistics.
>
> I've set the max to 4,000,000,000 .... I acrtually see one of my hosts do
> 1.5G every night for a couple hours.
>
> /usr/bin/rrdtool create \
> /usr/share/cacti/rra/crush_net_unc_edu_query_116761.rrd \ --step 300  \
> DS:query:COUNTER:600:0:4000000000 \
> DS:notify:COUNTER:600:0:4000000000 \
> RRA:AVERAGE:0.5:1:500 \
> RRA:AVERAGE:0.5:1:600 \
> RRA:AVERAGE:0.5:6:700 \
> RRA:AVERAGE:0.5:24:775 \
> RRA:AVERAGE:0.5:288:797 \
> RRA:MAX:0.5:1:500 \
> RRA:MAX:0.5:1:600 \
> RRA:MAX:0.5:6:700 \
> RRA:MAX:0.5:24:775 \
> RRA:MAX:0.5:288:797 \
>
> So, what happens is, if the bind process gets restarted, the data goes
> back to zero and I get a 4G spike on my graph.
>
> Any ideas on fixing that?  Should I use derive instead of counter to fix
> it up?
>
> _______________________________________________
> rrd-users mailing list
> [email protected]
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>
> _______________________________________________
> rrd-users mailing list
> [email protected]
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>
>


-- 
Donovan Baarda <[email protected]>

_______________________________________________
rrd-users mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users