PR #3 introduced a static 30s duration to repeat measurements for in case the current time drift is above 10ms. Anyhow, 30s duration does not work well in case when we have Prometheus scrape timeout configured to a smaller number (e.g. 10s). In this case, the scrape timeouts, without getting results from the exporter.
This PR allows to override (still keeping 30s as default to avoid breaking existing setups) this measurement duration, allowing to reduce it to align it with Prometheus scrape timeout.
I've named the setting --ntp.measurement-duration, but please let me know if you think there's a better name for it 🙂
I've also added additional warning log message in case the drift was to high and multiple measurements were requires, so it's easier to indicate that's the case and know the exact values of high drift and measurement duration.
PR #3 introduced a static
30s
duration to repeat measurements for in case the current time drift is above10ms
. Anyhow,30s
duration does not work well in case when we have Prometheus scrape timeout configured to a smaller number (e.g.10s
). In this case, the scrape timeouts, without getting results from the exporter.This PR allows to override (still keeping
30s
as default to avoid breaking existing setups) this measurement duration, allowing to reduce it to align it with Prometheus scrape timeout.I've named the setting
--ntp.measurement-duration
, but please let me know if you think there's a better name for it 🙂I've also added additional
warning
log message in case the drift was to high and multiple measurements were requires, so it's easier to indicate that's the case and know the exact values ofhigh drift
andmeasurement duration
.