fix(slo): history details data

[kdelemme]

Resolves #182251

🌮 Summary

This PR fixes the calculation of the historical summary data when an ad-hoc date range is provided. Indeed, when querying the SLI data for a rolling SLO with a provided date range, we need to query since the start of the range minus the slo rolling window duration. Otherwise the cumulative sum is not correct.

One way to see it is that when we zoom into the chart, the values should not change (when keeping the same bucket sizes, i.e when the range duration is in the same order of magnitude than the time window duration)

I'm also cleaning up the range type, by keeping only one common type, e.g. using Date type. I think that string or number for representing dates are dangerous, and difficult to follow in a codebase.

I also need to go back to the historical summary client and clean up the DateRange i've introduced to fix the issue aforementioned issue. it's not very clean, and pretty confusing at the moment. So far, I only came up with a comment. Any suggestion for improving this part of the code, getDateRange()?

I've used this to validate the tests: https://docs.google.com/spreadsheets/d/1uDoqq4sJPt2Dnksc1U2x6zAfQB73SK2udvweLl6ODuo/edit#gid=908013864

How to test

• Run data forge for 2 weeks: node x-pack/scripts/data_forge.js --events-per-cycle 50 --lookback now-14d --dataset fake_stack --install-kibana-assets --kibana-url http://localhost:5601/kibana
• Go get a coffee, it will take time
• Create an SLO over 7days rolling window (either Timeslices or Occurrences)
• When going to the history page without changing the time picker value, the historical charts should be the same than the overview page (look at the beginning of the chart)
• When zooming in with a date range > 3days (to keep the same bucket size interval for the calculations), any value should be equal to the previously shown value for the same date.

historical.slo.page.mov

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[kdelemme]

/ci

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

[shahzad31]

can you please explain why this post-filtering is required?

[shahzad31]

LGTM , works as expected now , even for smaller ranges !!

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: f24ddb8
• Storybooks Preview
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-183097-f24ddb822d1e
• Observability Deployment

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
slo	869.7KB	869.3KB	-416.0B

Canvas Sharable Runtime

The Canvas "shareable runtime" is an bundle produced to enable running Canvas workpads outside of Kibana. This bundle is included in third-party webpages that embed canvas and therefor should be as slim as possible.

id	before	after	diff
module count	-	5405	+5405
total size	-	8.8MB	+8.8MB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
observability	151.5KB	151.4KB	-93.0B

History

• 💚 Build #209651 succeeded 3537956
• 💔 Build #209277 failed 29d4936

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream