Use proper metric type for counter values #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
a
andb
increment 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.