docs: instant queries don't return the actual sample timestamp#5708
docs: instant queries don't return the actual sample timestamp#5708dandv wants to merge 1 commit into
Conversation
It is the perspective of view. If you think of VictoriaMetrics or Prometheus like about systems allowing you to view a state of other systems - it becomes more understandable. Each system has its state, all the time, whenever we'll decide to observe. But the system can't report its state to monitoring system instantly. It does it periodically, like each 30s it sends a snapshot of its state in the form of metrics (a scrape). So VM and Prometheus assumes that when you query the metric, you observe its state at the moment you queried it. It abstracts the fact of when this state was last updated, or how frequently it is updated. You just ask: "what's the cpu usage of system Foo". And VM responds: "it is 40% now, from what I can tell". It doesn't say: "it was 40% 15s ago". This would be observing not the state, but events. So think of VM/Prometheus like systems that show state, while Influx/Timescale/etc. show events. |
|
Closing this PR in favour of b5978ed |
…rned by instant and range queries Do not use `raw samples` term there, since it adds more confusion than clarity: the `raw samples` refers to real samples stored in the database, while neither range nor instant queries do not return raw samples - they both return *calculated* samples at *the given* timestamps. This is a follow-up for b5978ed Updates #5710 Updates #5708
…rned by instant and range queries Do not use `raw samples` term there, since it adds more confusion than clarity: the `raw samples` refers to real samples stored in the database, while neither range nor instant queries do not return raw samples - they both return *calculated* samples at *the given* timestamps. This is a follow-up for b5978ed Updates #5710 Updates #5708
2 participants
This behavior is counter-intuitive and quite annoying when I want to get the actual timestamp of the last event in a series.
What is the utility of returning the timestamp provided by the caller, instead of the actual timestamp of the sample?