GraphiteHandler sends ntpd.offset value as 0

[sacharv]

moved this issue from the old repo to this one (if I shouldn't have don this p[lease let me know)

I switched from the GraphitePickleHandler to the GraphiteHandler yesterday and noticed that all ntpd offset values where suddenly reported as 0. When looking into this I noticed when I switch back to the GraphitePickleHandler the correct value is being sent, in this case: 0.00162993

ntpdc -c kerninfo pll offset: 0.00162993 s pll frequency: -9.166 ppm maximum error: 0.267084 s estimated error: 0.01685 s status: 2001 pll nano pll time constant: 7 precision: 1e-09 s frequency tolerance: 500 ppm To verify I enabled the ArchiveHandler to see what is being logged by that handler and it also logs 0 while I see the correct value from the GraphitePickleHandler.

Running diamond in debug mode did not show any errors

first observed with version 3.3.510 and still and issue in version 4.0.60

[zzl0]

@sacharv I have encountered this bug too. I found many collectors didn't specify the precision parameter (it's default value is 0), and when use GraphiteHandler to send metric, the precision will cause this bug, the fractional-part will be dropped.

## The following is copyed from Metric.__repr__ function

# Set the format string
fstring = "%%s %%0.%if %%i\n" % self.precision

# Return formated string
return fstring % (self.path, self.value, self.timestamp)

There are many ways to fix this bug:

• Change the default value of precision (e.g. precision=3)
• Compute the precision dynamically according to the value of metric. e.g.

precision = 0 if value > 50 else 3

• Add precision parameter to all collectors.

@mattrobenolt @kormoc @rtoma @josegonzalez Can you give me some suggestions to fix this bug ?