Cassandra Time Synchronization Monitoring
Time synchronization is an operational dependency and should be monitored as one. What the signals below protect is the timestamp ordering described in How Cassandra uses time: a host whose clock has stopped being disciplined writes data that is wrong on read, without producing an error. Silence from the time daemon is not evidence that the clock is right; chronyd continues running with Leap status: Not synchronised when it has lost all its sources.
The diagram below shows what is being measured and by which component on a single host. chronyd reads chrony.conf, talks to the configured Network Time Protocol (NTP) servers, and disciplines the system clock. The AxonOps agent reads the same system clock and independently queries the NTP servers, which is how it produces an offset figure rather than merely reporting what chronyd believes.
What to collect
Section titled “What to collect”What to collect from every Cassandra node and every client application host:
- Offset against the synchronization source, from
chronyc tracking(System timeandLast offset). - Pairwise offset across the cluster, computed by comparing the per-node offsets centrally. This is the measurement that corresponds to what Cassandra depends on, and it is the one a per-node check cannot produce.
- Jitter, as
RMS offsetand the per-source standard deviation fromchronyc sourcestats. Rising jitter precedes rising offset. - Stratum, and the identity of the reference source. A node that has silently fallen back to a different source, or to a much higher stratum, has lost its intended reference.
- Source reachability, from the
Reachcolumn ofchronyc sources, and the count of sources currently selectable. Persistent values below377indicate loss. - Synchronization state, from
Leap status. Anything other thanNormalis an alert in its own right. - Step events, from the chrony log. A step on a running Cassandra node is an incident, not a routine correction.
The commands that produce these readings, and what healthy output looks like, are covered in Configuring chrony.
The degradation from three reachable tier servers to one is the case worth designing the alerting around, because the obvious signal does not fire for it. While at least one source is still selected and the minsources threshold is met, Leap status stays Normal and the reported offset stays small, so a check that watches only those two fields sees a healthy node. Two signals do catch it: the source reachability count, which drops as servers are lost, and the pairwise node-to-node offset comparison, which widens once different nodes fall back to different remaining sources. Both should be alerted on independently of Leap status, since by the time Leap status changes the node has already stopped being disciplined.
Suggested thresholds
Section titled “Suggested thresholds”Suggested starting thresholds, to be tuned to the workload rather than treated as limits:
| Signal | Warning | Investigate immediately |
|---|---|---|
| Offset against source | above 10 ms | above 100 ms |
| Pairwise skew between any two nodes | above 10 ms | above 100 ms |
| Leap status | not Normal for more than one poll interval | not Normal sustained |
| Source reachability | Reach below 377 | all sources unreachable |
A workload that issues conflicting writes to the same cells at intervals shorter than 10 ms requires correspondingly tighter thresholds, derived as described in How much skew is tolerable.
The AxonOps agent
Section titled “The AxonOps agent”The AxonOps agent (axon-agent) measures the NTP offset on each monitored Cassandra host and reports it as the host_ntp_offset_seconds metric, alongside the other host metrics, which makes the per-node offsets available for the cluster-wide comparison described above. Where a dedicated internal NTP tier is in use, or where the agent’s automatic detection of the configured time source fails, which is the common case for Cassandra deployed on Kubernetes, the NTP: section of /etc/axonops/axon-agent.yml lists the servers the agent measures against, with port 123 assumed if no port is given. See AxonOps agent configuration for the agent configuration file.
Related pages
Section titled “Related pages”- Clock skew failure modes - what the alerts are protecting against
- Configuring chrony - the verification commands behind these signals