add support for derivative metrics #22

Open
wants to merge 3 commits into
from

Conversation

Projects
None yet
2 participants
@hollow

hollow commented Sep 12, 2012

A derivative metric is like a meter but accepts an absolute counter as
input. This is useful for metrics like bytes sent over the network or
cpu cycles which are generally monotonically increasing counters and
therefore need to be derived from the previous sample to get a useful
rate/s value.

Benedikt Böhm added some commits Sep 12, 2012

Benedikt Böhm
add support for derivative metrics
A derivative metric is like a meter but accepts an absolute counter as
input. This is useful for metrics like bytes sent over the network or
cpu cycles which are generally monotonically increasing counters and
therefore need to be derived from the previous sample to get a useful
rate/s value.
+module Metriks
+ class Derive < Metriks::Meter
+ def mark(val = 1)
+ @last ||= Atomic.new(val)

This comment has been minimized.

Show comment Hide comment
@eric

eric Oct 28, 2012

Owner

This needs to be initialized in the constructor to be threadsafe.

@eric

eric Oct 28, 2012

Owner

This needs to be initialized in the constructor to be threadsafe.

+ def mark(val = 1)
+ @last ||= Atomic.new(val)
+ last = @last.swap(val)
+ super(last > val ? val : val - last)

This comment has been minimized.

Show comment Hide comment
@eric

eric Oct 28, 2012

Owner

One problem with doing this simplistically is that the rate calculations, etc. are all updated every 5 seconds. If a counter is polled (and mark() is called) less frequently than 5 seconds, the rates will be recorded as all happening right when mark() was called instead of something more reasonable (like linearly from the last time it was polled and now).

I'll have to dig into the underlying classes more to see if there's a reasonable way to do this sort of thing, but it may be that a meter isn't the right thing to be using as an underlying implementation for a derived counter.

@eric

eric Oct 28, 2012

Owner

One problem with doing this simplistically is that the rate calculations, etc. are all updated every 5 seconds. If a counter is polled (and mark() is called) less frequently than 5 seconds, the rates will be recorded as all happening right when mark() was called instead of something more reasonable (like linearly from the last time it was polled and now).

I'll have to dig into the underlying classes more to see if there's a reasonable way to do this sort of thing, but it may be that a meter isn't the right thing to be using as an underlying implementation for a derived counter.

@eric

This comment has been minimized.

Show comment Hide comment
@eric

eric Dec 7, 2012

Owner

I think we should make a derivative metric not inherit from Meter.

The things to consider are:

  1. How often is the derived metric going to be updated?
  2. How often is the reporter going to report on the metric?
  3. What should happen if the derived metric hasn't been updated since the last report?
  4. What should happen if the derived metric has been updated more than once since the last report?

With the Meter we have, we expect that we will be incrementing it as things happen, but with this derived metric, we are (I would guess) expecting to update it on a regular interval, so it has a lot of different implications.

Owner

eric commented Dec 7, 2012

I think we should make a derivative metric not inherit from Meter.

The things to consider are:

  1. How often is the derived metric going to be updated?
  2. How often is the reporter going to report on the metric?
  3. What should happen if the derived metric hasn't been updated since the last report?
  4. What should happen if the derived metric has been updated more than once since the last report?

With the Meter we have, we expect that we will be incrementing it as things happen, but with this derived metric, we are (I would guess) expecting to update it on a regular interval, so it has a lot of different implications.

@hollow

This comment has been minimized.

Show comment Hide comment
@hollow

hollow Dec 11, 2012

In my case:

  1. every second
  2. just like for any other metric?

since i collect these metrics every second, i don't really care about the other two, but i would suggest something like:

  1. & 4. nothing or something invalid (like -∞)

probably do it similar to RRDtool, people are already familiar how DERIVE works with RRAs

hollow commented Dec 11, 2012

In my case:

  1. every second
  2. just like for any other metric?

since i collect these metrics every second, i don't really care about the other two, but i would suggest something like:

  1. & 4. nothing or something invalid (like -∞)

probably do it similar to RRDtool, people are already familiar how DERIVE works with RRAs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment