Hey Chris, Brian. Thanks for your replies/confirmations.
On Sunday, March 24, 2024 at 8:16:14 AM UTC+1 Ben Kochie wrote: Yup, this is correct. Prometheus sets the timestamp of the sample at the start of the scrape. But since it's an ACID compliant database, the data is not queryable until after it's been fully ingested. This is intentional, because the idea is that whatever atomicity is desired by the target is handled by the target. Any locks taken are done when the target receives the GET /metrics. The exposition formatting, compression, and wire transfer time should not impact the "when time when the sample was gathered". Does make sense, yes... was that documented somewhere? I think it would be helpful if e.g. the page about the querying basics would tell, these two properties: - that data is only returned if it has fully arrived, and thus may not be, even if the query is after the sample time - that Prometheus "adjusts" the timestamps within a certain range And yes, the timing is a tiny bit faked. There are some hidden flags that control this behavior. --scrape.adjust-timestamps --scrape.timestamp-tolerance The default allows up to 2ms (+-0.002) of timing jitter to be ignored. This was added in 2020 due to a regression in the accuracy of the Go internal timer functions. See: https://github.com/prometheus/prometheus/issues/7846 Makes sense, too. And is actually vital for what I do over in https://groups.google.com/g/prometheus-users/c/BwJNsWi1LhI/m/ik2OiRa2AAAJ Just out of curiosity, what happens, if the jitter is more than the +-0.002? Thanks, Chris. -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/ce9bc4cb-6c93-4df0-93ed-cc83e1e17f80n%40googlegroups.com.
