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.