While that will work for a single go-metrics registry reporting to DogStatsD, whenever more multiple registries increment the same counter (e.g. from multiple processes or containers on the same host), intermediate values will be lost.
Say, for example, that two instances a and b increment the same counter multiple times during a DogStatsD flush interval (reporting is ordered chronologically from left to right):
a: 0 2 3
b: 0 1 2
With a counter type, one would expect the value submitted to datadog for the flush interval to be 5—increments are submitted and added by the DogStatsD during the flash interval. However, a gauge only keeps and submits the last value, in this case 3 which is incorrect.
This MR fixes this by using the count type for histogram, meter, and timer counters.
Counter and rate type metrics shouldn't be backed by a DogStatsD gauge because only the last value in the flush interval is submitted for gauges.
While that will work for a single go-metrics registry reporting to DogStatsD, whenever more multiple registries increment the same counter (e.g. from multiple processes or containers on the same host), intermediate values will be lost.
Say, for example, that two instances
aandbincrement the same counter multiple times during a DogStatsD flush interval (reporting is ordered chronologically from left to right):With a counter type, one would expect the value submitted to datadog for the flush interval to be
5—increments are submitted and added by the DogStatsD during the flash interval. However, a gauge only keeps and submits the last value, in this case 3 which is incorrect.This MR fixes this by using the count type for histogram, meter, and timer counters.