We depend on the API request to fetch the from and to date parameters for fetching usage data with monitoring.
We can remove this from the API and instead only send timestamp. The api can decide the from/to interval internally.
At the moment we have some cases where we override the 20 minutes interval sent from the browser.
CC @afharo
Pinging @elastic/pulse (Team:Pulse)
I think it makes perfect sense!
But it may require some additional changes (apart from providing timestamp instead of from and to) in the way the usageCollection manager calls the fetchers?
With the current telemetry, we only return snapshots, so I guess it will be fine for the usageCollector to define the query time range based on that unique timestamp.
But as we are approaching the Pulse logic, and more granular time-based data is supposed to come in, we may need to keep in mind an additional lastSuccessfulReport so we don't report the same data twice? It certainly is not related to this issue (or is it?) but just an open thought here.
@afharo i dont believe we should be relying on the user's timestamp at all. for the aggregate data (currnet telemetry) we can just send the latest snapshot regardless or user time. for event based documents (pulse documents) we can send documents based on the last reported timestamp or something. The team should discuss this further before writing an implementation.
Most helpful comment
@afharo i dont believe we should be relying on the user's timestamp at all. for the aggregate data (currnet telemetry) we can just send the latest snapshot regardless or user time. for event based documents (pulse documents) we can send documents based on the last reported timestamp or something. The team should discuss this further before writing an implementation.