Graphite

Simple graph of counters

Asked by Mohan on 2012-04-24

I am streaming movingAverage:4|c continuosly to graphite using statsd and was expecting this value to rise from 0 to 4 and stay there. But the graph's shape is not a continuous straight line because the graph drops below 4 sometimes.

I am not sure why the value drops to 3.5 or 3.6 sometimes.

I use statsd and the statsd log also shows only movingAverage:4|c always. I am a beginner and might be overlooking something.

Thanks.

Question information

Language:
English Edit question
Status:
Solved
For:
Graphite Edit question
Assignee:
No assignee Edit question
Solved by:
Mohan
Solved:
2012-04-30
Last query:
2012-04-30
Last reply:
2012-04-24
Michael Leinartas (mleinartas) said : #1

What is your statsd flushInterval and your lowest-precision in your storage-schemas.conf (they should match)? How often are you sending the count to statsd?

Are you looking at "stats.movingAverage" or "stats_counts.movingAverage"? Statsd puts the raw counts received into stats_counts but puts a per-second average (total count over the flushInterval divided by the flushInterval) in the 'stats' tree.

Mohan (radhakrishnan-mohan) said : #2

 flustInterval: 1000

[stats]
priority = 110
pattern = .*
retentions = 10:2160,60:10080,600:262974

I am viewing stats_counts.movingAverage.

Moreover I have changed the algo. that sends moving averages and it looks like the values are appropriated drawn in the graph now. So there doesn't seem to be any problem now but I have to check.

What is the lowest-precision in the storage-schemas.conf you mean ?

Thanks.

Michael Leinartas (mleinartas) said : #3

Sorry, I should have said "*highest* precision" (which is also the lowest retention). In this case, your highest precision is 10 seconds per point which does match the default for statsd. These values not matching are sometimes a cause of missing or unexpected values is why I asked.

Mohan (radhakrishnan-mohan) said : #4

Thanks.