Skip to content

ChronyHighStratum threshold tuning #21

Description

@zabaj1

Bug Description

We have a cloud enviroment where the machines running chrony-client are occasionally getting sources with stratum 4.
This can happen when the cloud node acting as NTP server syncs to stratum 3 timeservers, even when using high-quality timeservers such as uk.pool.ntp.org, and then redistributes the time to other machines as a stratum 4 timeserver. This is not an unusual design.

A ChronyHighStratum alert [1] is raised but a NTP source with a stratum value of 4 should still be considered acceptable and this alert is treated as a false positive.

I'm opening this issue to start a discussion about the right threshold value for this alert: we can evaluate raising the threshold to a very high value (e.g. 10) and/or alerting based on different criteria such as reachability and offset.

[1] https://github.com/canonical/chrony-operators/blob/main/chrony-client-operator/src/prometheus_alert_rules/chrony.rule

Impact

Low (minor issue or cosmetic problem)

Impact Rationale

This alert is considered a false positive

To Reproduce

  1. Have a NTP source with stratum 3 (or run a NTP server and manually set its advertised stratum to 4)
  2. Configure the server as source for chrony-client
  3. Check the ChronyHighStratum alert

Environment

Juju 3.6.25 with charm revision 52

Relevant log output

N/A

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions