Node_Exporter/vendor/github.com/beevik/ntp/README.md

[![Build Status](https://travis-ci.org/beevik/ntp.svg?branch=master)](https://travis-ci.org/beevik/ntp)
[![GoDoc](https://godoc.org/github.com/beevik/ntp?status.svg)](https://godoc.org/github.com/beevik/ntp)

ntp
===

The ntp package is an implementation of a simple NTP client. It allows you
to connect to a remote NTP server and request the current time.

To request the current time, simply do the following:
```go
time, err := ntp.Time("0.beevik-ntp.pool.ntp.org")
```

To request the current time along with additional metadata, use the Query
function:
```go
response, err := ntp.Query("0.beevik-ntp.pool.ntp.org")
```

NB: if you want to use the NTP Pool in your software you should request your
own [vendor zone](http://www.pool.ntp.org/en/vendors.html).  You **must
absolutely not use the default pool.ntp.org zone names** as the default
configuration in your application or appliance.
Use the offset calculation that includes round trip time in the ntp collector Previously the raw time difference was used which includes the network trip time between the node and the ntp server. This makes setting alerts off the value troublesome as it depends on the latency as well as the clock offset. 2016-06-01 09:56:20 +02:00			`[![Build Status](https://travis-ci.org/beevik/ntp.svg?branch=master)](https://travis-ci.org/beevik/ntp)`
			`[![GoDoc](https://godoc.org/github.com/beevik/ntp?status.svg)](https://godoc.org/github.com/beevik/ntp)`

Vendor all dependencies Uses godep to vendor dependencies. Godeps is not necessary during build, golang's new vendor support is used instead. 2016-01-21 04:19:15 +01:00			`ntp`
			`===`

Update vendored packages 2017-02-28 22:59:37 +01:00			`The ntp package is an implementation of a simple NTP client. It allows you`
			`to connect to a remote NTP server and request the current time.`
Vendor all dependencies Uses godep to vendor dependencies. Godeps is not necessary during build, golang's new vendor support is used instead. 2016-01-21 04:19:15 +01:00
Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check (#655) * Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check 1. Checking local clock against remote NTP daemon is bad idea, local ntpd acting as a client should do it better and avoid excessive load on remote NTP server so the collector is refactored to query local NTP server. 2. Checking local clock against remote one does not check local ntpd itself. Local ntpd may be down or out of sync due to network issues, but clock will be OK. 3. Checking NTP server using sanity of it's response is tricky and depends on ntpd implementation, that's why common `node_ntp_sanity` variable is exported. * `govendor add golang.org/x/net/ipv4`, it is dependency of github.com/beevik/ntp * Update github.com/beevik/ntp to include boring SNTP fix * Use variable name from RFC5905 * ntp: move code to make export of raw metrics more explicit * Move NTP math to `github.com/beevik/ntp` * Make `golint` happy * Add some brief docs explaining `ntp` #655 and `timex` #664 modules * ntp: drop XXX comment that got its decision * ntp: add `_seconds` suffix to relevant metrics * Better `node_ntp_leap` comment * s/node_ntp_reftime/node_ntp_reference_timestamp_seconds/ as requested by @discordianfish * Extract subsystem name to const as suggested by @SuperQ 2017-09-19 10:36:14 +02:00			`To request the current time, simply do the following:`
Update vendored packages 2017-02-28 22:59:37 +01:00			```go
Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check (#655) * Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check 1. Checking local clock against remote NTP daemon is bad idea, local ntpd acting as a client should do it better and avoid excessive load on remote NTP server so the collector is refactored to query local NTP server. 2. Checking local clock against remote one does not check local ntpd itself. Local ntpd may be down or out of sync due to network issues, but clock will be OK. 3. Checking NTP server using sanity of it's response is tricky and depends on ntpd implementation, that's why common `node_ntp_sanity` variable is exported. * `govendor add golang.org/x/net/ipv4`, it is dependency of github.com/beevik/ntp * Update github.com/beevik/ntp to include boring SNTP fix * Use variable name from RFC5905 * ntp: move code to make export of raw metrics more explicit * Move NTP math to `github.com/beevik/ntp` * Make `golint` happy * Add some brief docs explaining `ntp` #655 and `timex` #664 modules * ntp: drop XXX comment that got its decision * ntp: add `_seconds` suffix to relevant metrics * Better `node_ntp_leap` comment * s/node_ntp_reftime/node_ntp_reference_timestamp_seconds/ as requested by @discordianfish * Extract subsystem name to const as suggested by @SuperQ 2017-09-19 10:36:14 +02:00			`time, err := ntp.Time("0.beevik-ntp.pool.ntp.org")`
Update vendored packages 2017-02-28 22:59:37 +01:00			```
Vendor all dependencies Uses godep to vendor dependencies. Godeps is not necessary during build, golang's new vendor support is used instead. 2016-01-21 04:19:15 +01:00
Update vendored packages 2017-02-28 22:59:37 +01:00			`To request the current time along with additional metadata, use the Query`
			`function:`
			```go
Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check (#655) * Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check 1. Checking local clock against remote NTP daemon is bad idea, local ntpd acting as a client should do it better and avoid excessive load on remote NTP server so the collector is refactored to query local NTP server. 2. Checking local clock against remote one does not check local ntpd itself. Local ntpd may be down or out of sync due to network issues, but clock will be OK. 3. Checking NTP server using sanity of it's response is tricky and depends on ntpd implementation, that's why common `node_ntp_sanity` variable is exported. * `govendor add golang.org/x/net/ipv4`, it is dependency of github.com/beevik/ntp * Update github.com/beevik/ntp to include boring SNTP fix * Use variable name from RFC5905 * ntp: move code to make export of raw metrics more explicit * Move NTP math to `github.com/beevik/ntp` * Make `golint` happy * Add some brief docs explaining `ntp` #655 and `timex` #664 modules * ntp: drop XXX comment that got its decision * ntp: add `_seconds` suffix to relevant metrics * Better `node_ntp_leap` comment * s/node_ntp_reftime/node_ntp_reference_timestamp_seconds/ as requested by @discordianfish * Extract subsystem name to const as suggested by @SuperQ 2017-09-19 10:36:14 +02:00			`response, err := ntp.Query("0.beevik-ntp.pool.ntp.org")`
Update vendored packages 2017-02-28 22:59:37 +01:00			```
Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check (#655) * Add metrics from SNTPv4 packet to ntp collector & add ntpd sanity check 1. Checking local clock against remote NTP daemon is bad idea, local ntpd acting as a client should do it better and avoid excessive load on remote NTP server so the collector is refactored to query local NTP server. 2. Checking local clock against remote one does not check local ntpd itself. Local ntpd may be down or out of sync due to network issues, but clock will be OK. 3. Checking NTP server using sanity of it's response is tricky and depends on ntpd implementation, that's why common `node_ntp_sanity` variable is exported. * `govendor add golang.org/x/net/ipv4`, it is dependency of github.com/beevik/ntp * Update github.com/beevik/ntp to include boring SNTP fix * Use variable name from RFC5905 * ntp: move code to make export of raw metrics more explicit * Move NTP math to `github.com/beevik/ntp` * Make `golint` happy * Add some brief docs explaining `ntp` #655 and `timex` #664 modules * ntp: drop XXX comment that got its decision * ntp: add `_seconds` suffix to relevant metrics * Better `node_ntp_leap` comment * s/node_ntp_reftime/node_ntp_reference_timestamp_seconds/ as requested by @discordianfish * Extract subsystem name to const as suggested by @SuperQ 2017-09-19 10:36:14 +02:00
			`NB: if you want to use the NTP Pool in your software you should request your`
			`own [vendor zone](http://www.pool.ntp.org/en/vendors.html). You **must`
			`absolutely not use the default pool.ntp.org zone names** as the default`
			`configuration in your application or appliance.`