windows_exporter icon indicating copy to clipboard operation
windows_exporter copied to clipboard

How to detect clock skew or lack of system clock synchronisation

Open rdiez opened this issue 2 years ago • 3 comments

Is there a way to detect clock skew or lack of system clock synchronisation?

The 'time' collector is documented to work only Windows Server 2016 or newer, but I want to detect this condition on normal Windows PCs too.

As a source for inspiration, here are some rules that should do the trick for the Node Exporter (for Linux/Unix hosts):

Host clock skew Host clock not synchronising https://awesome-prometheus-alerts.grep.to/rules#host-and-hardware

rdiez avatar Nov 13 '21 15:11 rdiez

windows_time_computed_time_offset_seconds from the time collector would be the most suitable metric for this.

I've tested this on a Windows 11 VM, and the metric is updated every 30 minutes. You could use this with windows_time_ntp_client_time_source_count to determine if the NTP client is active (0 indicating no NTP sources).

breed808 avatar Nov 21 '21 08:11 breed808

As I stated above, the 'time' collector is documented to work only Windows Server 2016 or newer.

Do you mean then that Windows 11 Pro (non server) also supports the necessary Time Service perflib counters? Or is the documentation wrong, and Windows 10 Home or Pro has them too?

Besides, windows_time_computed_time_offset_seconds is documented as "Absolute time offset between the system clock and the chosen time source, in seconds.". That probably wouldn't work if the system cannot reach any time servers.

I would have thought that windows_time_ntp_client_time_source_count would be a better way. If > 0, the system has found one time source. The question is, if the system synchronises its clock with the domain controller (when the computer has joined a domain), does the domain controller count as an NTP time source?

rdiez avatar Nov 21 '21 22:11 rdiez

As I stated above, the 'time' collector is documented to work only Windows Server 2016 or newer.

Apologies, I missed that part of your original post.

Do you mean then that Windows 11 Pro (non server) also supports the necessary Time Service perflib counters?

Yes, in my case this was with Windows 11 Pro. The note in the documentation was intended for Windows Server (I.E. Windows Server >= 2016 will have the metrics), as most desktop versions of Windows remain untested.

I would have thought that windows_time_ntp_client_time_source_count would be a better way. If > 0, the system has found one time source. The question is, if the system synchronises its clock with the domain controller (when the computer has joined a domain), does the domain controller count as an NTP time source?

I would assume that yes, a DC will count as an NTP time source.

breed808 avatar Nov 22 '21 01:11 breed808

Hello, I have a related problem, I have tried to observe if windows_time_computed_time_offset_seconds is really works as I expected (I wasn't sure if I understood the documentation correctly).

I've used Set-Date -Adjust -0:10:0 -DisplayHint Time ps command to get an alarm with prometheus, however I never get this metric show correctly:

resim

I confirmed the time difference with w32tm /stripchart /computer:foo, the output is like this:


PS C:\Users\baruser> w32tm /stripchart /computer:foo.my.domain
Tracking foo.my.domain [x.y.z.t:123].
The current time is 1.02.2023 14:34:59.
14:34:59, d:+00.0002322s o:+600.0106644s  [                           |                          @]
14:35:01, d:+00.0003498s o:+600.0107934s  [                           |                          @]

Both my ntp client and server are server 2019, what am i missing? My windows_exporter version is 0.20.0

mayeter avatar Feb 01 '23 12:02 mayeter

@callMe-Root is Perflib returning the same metric values? You could watch with:

while ($true) {
    Get-Counter -Counter '\Windows Time Service\Computed Time Offset'
    Start-Sleep -Seconds 1
}

breed808 avatar Feb 18 '23 01:02 breed808

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

github-actions[bot] avatar Nov 25 '23 02:11 github-actions[bot]