Closed teepark closed 8 years ago
Thanks @teepark. Looks good. The Uint64Slice
code can be removed. Since we are moving closer to the official statsd specs do you want to take a stab at supporting floats for all metric types?
https://github.com/b/statsd_spec
worth mentioning that @jsocol's pystatsd recently started sending floats for all timings (so I had to temporarily back down to pystatsd-3.1)
I agree that supporting floats is a good idea, but I don't think those "official statsd specs" support the idea:
The protocol allows for both integer and floating point values. Most implementations store values internally as a IEEE 754 double precision float, but many implementations and graphing systems only support integer values. For compatibility all values should be integers in the range (-2^53^, 2^53^)
@teepark This looks good. Can you rebase/squash off of master when you get a chance?
@ploxiln Agreed on the official docs indicating it's not fully supported/encouraged. Given that we only output to graphite at the moment which supports floats, this feels like an OK change.
@markrechler all rebased and squashed!
I was having trouble with go-statsd-client and realized the issue was server-side: timers are being parsed as uint64s, but decimal points are allowed. evidence