Add ntp collector

[shortdudey123]

Collect out of band stats from ntp

Uses output from ntpdate:

$ ntpdate -q pool.ntp.org
server 12.34.56.1, stratum 2, offset -0.000277, delay 0.02878
server 12.34.56.2, stratum 1, offset -0.000128, delay 0.02896
server 12.34.56.3, stratum 2, offset 0.000613, delay 0.02870
server 12.34.56.4, stratum 2, offset -0.000351, delay 0.02864
31 Apr 12:00:00 ntpdate[12]: adjust time server 12.34.56.2 offset -0.000128 sec
$

[coveralls]

Coverage remained the same at 59.217% when pulling 2cc59d1 on BanjoInc:create_ntp_collector into cd851af on python-diamond:master.

[coveralls]

Coverage decreased (-0.8%) to 58.41% when pulling e867c5a on BanjoInc:create_ntp_collector into cd851af on python-diamond:master.

[coveralls]

Coverage decreased (-0.8%) to 58.41% when pulling 5b0734f on BanjoInc:create_ntp_collector into cd851af on python-diamond:master.

[shortdudey123]

Hey @jaingaurav
Can you look at this PR? as well as a couple of my other ones? Thanks!!!

[jaingaurav]

So rather than having all these offset stats, how about you have the unit and precision in the config as an option and then use the unit conversion utils?

[shortdudey123]

ah, do you have a good example of that?

[jaingaurav]

https://github.com/python-diamond/Diamond/blob/master/src/collectors/uptime/uptime.py#L44

[shortdudey123]

@jaingaurav made changes per feedback
Will squash this down when you are good with the PR

[coveralls]

Coverage remained the same at 59.217% when pulling 3089f92 on BanjoInc:create_ntp_collector into cd851af on python-diamond:master.

[coveralls]

Coverage remained the same at 59.217% when pulling d79ded1 on BanjoInc:create_ntp_collector into 7578c1b on python-diamond:master.

[jaingaurav]

So maybe I wasn't quite clear, but my suggestion was why not use a configuration option such as units and then only have a single offset metric published, or am I missing something here? Also you may want to expose a precision option too then.

[shortdudey123]

I was looking to have atleast msec and usec exposed but i just exposed sec as well

Is it safe to make the assumption that people are ok with their metric changing scale if they change the config option on a single metric namespace? (i.e. having sec and msec on the same metric name)

[jaingaurav]

So why do you want both msec and usec exposed?

Regarding your latter point, you can stick with the style that the uptime collector has or use a suffix like you've currently done.

[shortdudey123]

So why do you want both msec and usec exposed?

Actually, i looked a bit more and in reality i only need one

you can stick with the style that the uptime collector has or use a suffix like you've currently done.

I looked more at the uptime collector, and it sends the metrics in a different namespace depending on the scale you use. I missed that so its probably better if i follow that style :)

[shortdudey123]

@jaingaurav updated

[coveralls]

Coverage remained the same at 59.217% when pulling 7ed10b2 on BanjoInc:create_ntp_collector into c0544c0 on python-diamond:master.

[coveralls]

Coverage remained the same at 59.217% when pulling d6ef032 on BanjoInc:create_ntp_collector into d0e6bc8 on python-diamond:master.

[shortdudey123]

@jaingaurav changed server_count to server.count and squashed :)

[coveralls]

Coverage remained the same at 59.217% when pulling 98dd405 on BanjoInc:create_ntp_collector into d0e6bc8 on python-diamond:master.

[jaingaurav]

Thanks a lot