Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StatsD reporting of availability metrics is broken #365

Open
kkonstan-ovo opened this issue Jun 10, 2022 · 0 comments · May be fixed by #367
Open

StatsD reporting of availability metrics is broken #365

kkonstan-ovo opened this issue Jun 10, 2022 · 0 comments · May be fixed by #367

Comments

@kkonstan-ovo
Copy link

kkonstan-ovo commented Jun 10, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant