You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However for some reason this double → long → double round trip is done and it drops all digits after the decimal point. There’s no record of why this was done in git history as it’s part of the original commit that adds the statsd functionality.
This makes statsd unsuitable for the availability metrics, which are gauges ranging from 0 to 1.
We'll be forking and testing a modified version that doesn't do that conversion, and am happy to create a PR, but this might change the behaviour for all other metrics which are actually integer counters.
The text was updated successfully, but these errors were encountered:
The availability metrics are reported to statsd as either 0 or 1.
We tracked it down to this bit of code:
new Double(attributeValue.value()).longValue()
kafka-monitor/StatsdMetricsReporterService.java at master · linkedin/kafka-monitor
The statsd client handles double:
https://github.com/tim-group/java-statsd-client/blob/master/src/main/java/com/timgroup/statsd/StatsDClient.java#L99
The metric value is stored as double:
kafka-monitor/MbeanAttributeValue.java at master · linkedin/kafka-monitor
However for some reason this double → long → double round trip is done and it drops all digits after the decimal point. There’s no record of why this was done in git history as it’s part of the original commit that adds the statsd functionality.
This makes statsd unsuitable for the availability metrics, which are gauges ranging from 0 to 1.
We'll be forking and testing a modified version that doesn't do that conversion, and am happy to create a PR, but this might change the behaviour for all other metrics which are actually integer counters.
The text was updated successfully, but these errors were encountered: