Chrony

Auto-Detection

Health Check

Built-in Metrics

Chrony is a versatile implementation of the Network Time Protocol (NTP).

chronyd and ntpd are detected as two different services — chrony and ntp — because they answer different protocols and report different metrics. Both share one dashboard and one metric category.

Auto-Detection

Bleemeo monitors the chrony time daemon through automatic service detection by process, an NTP service check, and built-in metrics read over chrony’s own command protocol on port 323. If the auto-detected parameters are incorrect, you can override them manually — stats_port is the command port.

Linux

sudo tee /etc/glouton/conf.d/99-chrony.conf > /dev/null << 'EOF'
service:
  # For a chronyd running outside a container
  - type: "chrony"
    stats_port: 323

  # For a chronyd running in a Docker container
  - type: "chrony"
    instance: "CONTAINER_NAME"
    stats_port: 323
EOF

Do not set address or port on a client-only chronyd

They are what tells Glouton the daemon serves NTP, so setting either makes it check UDP 123 instead of the command port. A chronyd that only syncs the local clock — the default install on most distributions — never listens there, and the check turns permanently critical. stats_port is the one to set: it names the command port and does not change which check is used.

Windows

chrony does not run on Windows. Windows hosts are covered by NTP.

Glouton automatically detects configuration changes.

Service Check

Which check Glouton runs is decided when the service is discovered, from the ports chronyd was seen listening on:

• chronyd listening on UDP 123 — a chrony configured as an NTP server, with an allow line — gets an NTP check on that port, the same one ntpd gets.
• chronyd not listening on UDP 123 gets a check on the command port instead. With no allow line chronyd only syncs the local clock.

Metric	Description
service_status	Status of chrony

Built-in Metrics

Metric	Description
chrony_last_offset	Estimated offset of the last Chrony clock update, in seconds
chrony_rms_offset	Chrony long-term average clock offset, in seconds
chrony_root_delay	Chrony total round-trip delay to the reference clock, in seconds
chrony_activity_online	Number of Chrony time sources currently reachable
chrony_activity_offline	Number of Chrony time sources currently unreachable

Metrics not Collected by Default

Chrony also reports one series per configured time source, carried by an ip label holding the source’s resolved address. On a host with many sources this is a lot of series for little benefit, so they are gathered but not sent unless you ask for them:

Metric	Description
chrony_sources_reachability_perc	Percentage of the last 8 polls of the Chrony time source that succeeded
chrony_sources_latest_measurement_seconds	Offset of the latest measurement from the Chrony time source, in seconds

Add them with metric.allow_metrics; see Metrics Filtering.

metric:
  allow_metrics:
    - "chrony_sources_reachability_perc"
    - "chrony_sources_latest_measurement_seconds"

Monitoring Troubleshooting

See Troubleshoot a Service Check or Missing Metrics for what applies to every service: finding the address and port Glouton really uses, what each check message means, and how to read the collection error — which does not appear in the agent logs at the default level.

The Service Check is not OK

The messages depend on which of the two checks this install gets. Those of the command-port check start with UDP port 323, — that prefix is how you tell the two apart.

chronyd serving NTP — the check on port 123:

Status text	Cause	Fix
NTP server not (yet) synchronized	chrony answers but has no usable time source of its own — often just after a restart	Wait for it to settle; if it persists, check its upstream servers
Local time and NTP time does not match	chrony’s time and the agent’s own clock differ by more than 10 seconds	Fix the clock on whichever side drifted
NTP server refused the request: ...	chronyd answered with a Kiss-o’-Death instead of the time: it is rate-limiting Glouton’s queries, or refusing them outright. The message says which	Relax chronyd’s ratelimit, or allow Glouton’s address
No data received from server	Nothing is listening on UDP 123	Check that chronyd is running and still has its allow line
Connection timed out after 10 seconds	The packets to UDP 123 are dropped	Open UDP 123

A client-only chronyd — the check on the command port:

Status text	Cause	Fix
UDP port 323, read udp …: connection refused	Nothing is listening on the command port: chronyd is down, its cmdport was changed (cmdport 0 disables it), or a bindcmdaddress line in /etc/chrony/chrony.conf moved it off 127.0.0.1	Check that chronyd is running, set stats_port to its cmdport, or remove the bindcmdaddress line and restart chronyd
UDP port 323, Connection timed out after 10 seconds	Nothing answered at all: a firewall drops the packets, or Glouton reaches chronyd on an address other than 127.0.0.1 and chronyd does not allow it. chronyd always allows localhost, and silently ignores the hosts its cmdallow lines leave out	Open UDP 323, or add a cmdallow line for the address Glouton connects from in /etc/chrony/chrony.conf and restart chronyd
No UDP address to check	chrony runs in a container whose address the runtime does not report	The container must not use network_mode: none or container:<other>

Metrics are Missing

Reproduce what Glouton does, from the machine where Glouton runs:

chronyc -h 127.0.0.1 tracking

What you see	Cause	Fix
506 Cannot talk to daemon	Nothing answered on the command port: chronyd is down, listening on another cmdport, moved off 127.0.0.1 by a bindcmdaddress line, or behind a firewall	Check that chronyd is running, that stats_port matches its cmdport, that /etc/chrony/chrony.conf has no bindcmdaddress line, and that UDP 323 is open
nothing, on a containerized chrony	The container’s address is not reported by the runtime	The container must not use network_mode: none or container:<other>
only the per-source metrics missing	They are not collected by default	See Metrics not Collected by Default