feat(slo): use burn rate rule definition for burn rate charts on SLO details page

[kdelemme]

Resolves https://github.com/elastic/kibana/issues/170605

🍒 Summary

This PR fetches the related SLO rules on the details page, and use the first rule defined windows to setup the burn rate charts windows as well as the threshold values for every windows. If an SLO has no rules, we fallback to default burn rate window definitions.

Testing

Load some data: node x-pack/scripts/data_forge.js --events-per-cycle 100 --lookback now-7d --dataset fake_stack --install-kibana-assets --kibana-url http://localhost:5601/kibana Then create three SLOs:

1. SLO one: delete its rule
2. SLO two: keep default rule
3. SLO three: Update default rule window duration/threshold definitions

When going to each SLO details page, you should see the right window/threshold used in the burn rate chart.

Label	Screenshot
SLO without rules defined
SLO with rules defined

[kdelemme]

/ci

[apmmachine]

:robot: GitHub comments

Expand to view the GitHub comments

Just comment with:

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

[elasticmachine]

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

[mgiota]

@kdelemme I tested this and it works well!

Here's one scenario that I tested, which requires a Browser refresh in order for the new changes to be reflected in the UI.

• Create an SLO
• Go to Rules page and delete the automatically generated rule
• Go back to the SLO details page
• Click Actions > Create new alert rule
• Update default values and Click Save in the Flyout
• You need to refresh the page to see the updated values.

https://github.com/elastic/kibana/assets/2852703/012b44a5-3829-433d-b4d8-791f308ab4e1

Could you handle refreshing the page when creating the rule from the SLO details page?

[mgiota]

@kdelemme I need one clarification regarding what you mention in the PR description about the wording of use the first rule defined. I guess you mean the most recent one created and not the first rule created, right? Here's the scenario I tested.

• Create an SLO
• A new rule gets automatically generated
• Go to SLO details page
• Click Actions > Create new alert rule
• Update default values and Click Save in the Flyout
• Refresh the broswser
• Updated changes get reflected in the UI, which means the most recent rule was picked up. And this is good, because if the first rule defined was used, then it would be confusing for the user.

Same issue with Refreshing the browser applies here as well.

[mgiota]

@kdelemme As discussed I approve this PR and we can handle the scenario, where a browser refresh is needed, in a follow up PR.

[kibana-ci]

:yellow_heart: Build succeeded, but was flaky

• Buildkite Build
• Commit: 07af5295b0df840db02b4625cf7a195cc043efd1
• Storybooks Preview

Failed CI Steps

• FTR Configs #4

Test Failures

• [job] [logs] FTR Configs #4 / Alerting transform alert rule types transform_health rule runs correctly

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
observability	661.6KB	662.1KB	+544.0B

History

• :green_heart: Build #194662 succeeded acfafc7e33cf463f9991957f4a8a5f21050e4e71
• :yellow_heart: Build #194387 was flaky c28670b3f795417e389dc6a3ab78fbbcf89b58b0
• :yellow_heart: Build #194243 was flaky 2de0bd3c41b769a1c0fb99faf5cae5e9590ada6e
• :yellow_heart: Build #194184 was flaky da4d0a67818ae3347ccf1ffd5aa0dd89d9c9ae76
• :green_heart: Build #194042 succeeded 7c7817ead70b308ac87a0c8d83467188d0de09db
• :broken_heart: Build #193967 failed 3578a6a240a2d581b96bfb7d4e4ea43494c9962d

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