← Back to team overview

graphite-dev team mailing list archive

[Question #206043]: Best practice for counter data

 

New question #206043 on Graphite:
https://answers.launchpad.net/graphite/+question/206043

I am asking about the recommended best practice for dealing with "counter" data, e.g. total number of messages received, which needs to be displayed as a rate, e.g. number of messages per second.

Should I feed the raw counter values directly into Graphite, or would I be better to convert them into rates first, using something like statsd?

I understand from https://answers.launchpad.net/graphite/+question/70553 that storing raw counters can work.

However I have some additional questions:

1. What is the maximum value for a counter value? Is it stored as an integer or as floating-point? (Single-precision floating point would only have effectively 23 bits of accuracy, and double-precision 47 bits; 64-bit counters would therefore not be usable)

2. What happens when a counter wraps around? Does the derivative() function take care of this? Does it assume that values are monotonically increasing, or would I get a huge negative spike when it wraps?

3. For a series of counter data, I note that the aggregation function would have to be set to "last" instead of the default "average".
http://graphite.readthedocs.org/en/1.0/config-carbon.html
Is there a best practice for this? For example, should I add ".counter" to the end of all metrics which are counters?

4. When plotting a graph, you have to ask for "derivative" in the UI. Can I configure it so that all metrics matching a particular pattern automatically use the derivative function? Otherwise there's an extra UI step involved every time you draw one of these, which would be a good reason for storing the rate in the first place.

5. As each counter value is submitted to graphite, it has a timestamp value. Does graphite/whisper store the exact timestamp against each data point, and use it when deriving rates? Or does it just use the timestamp to assign the data point into the nearest sample bin?

If the timestamps are stored it could display more accurate rates when samples are not taken at even intervals. However I don't know if this benefit would be realised in practice or not.


-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.