[SLO] Document the new alert details page for the SLO burn rate rule

[paulb-elastic]

Description

An alert details page is being created for the SLO burn rate rule, in elastic/kibana#174548. This needs to be documented.

Resources

The main PR is elastic/kibana#174548
The project, that includes links to other tasks, is https://github.com/elastic/observability-dev/issues/2985

Which documentation set does this change impact?

Stateful and Serverless

Feature differences

Same in stateful and serverless

What release is this request related to?

8.13

Collaboration model

The documentation team

Point of contact.

Main contact: @kdelemme

Stakeholders:

• @grabowskit
• @simianhacker

[bmorelli25]

Hey Paul. Will this be going into serverless before the 8.13 release? Or at the same time?

[paulb-elastic]

@bmorelli25 serverless won't have the same date as stateful, as it will be aligned with the PR being merged, then once it's been released to production

[dedemorton]

I'm trying to decide where this content should live. Looking at the current docs about viewing alerts, we describe the alert details page fairly generically, and the generic page is not accessible from the pages about creating rules. There's already a lot of info on the View alerts page, so I don't think we should try to add more detail to that page.

I'm assuming here that the person who sets up the rule will not be the person who monitors and responds to the alerts. If that's the case, we probably need to start building out new pages that describe how to view/triage specific types of alerts. So in the TOC we would have something like:

• View alerts - generic page
  • Triage SLO burn rate threshold breaches - describes alert details page
  • Triage custom threshold breaches - describes the alert details page
  • etc - we'll add pages as we add more specialized alert details pages

If goal oriented titles are too difficult, we could have:

• View alerts
  • View SLO burn rate rule alert details
  • View custom threshold alert details
  • etc

One thing I like about the goal-oriented approach is that we would not have to worry about making sure that we have a page for every rule type. (I definitely don't have time to build out all those pages right now.) Also I think focusing on real user goals is more meaningful to users than talking about our UI elements.

We should also make sure that the pages about creating rules have a section called something like "Next steps" that points to the generic View alerts page plus any alert details pages that we add.

Does this make sense? Am I on the right track here?

[mdbirnstiehl]

I'm partial to the goal-oriented approach, and I think it would provide a more comprehensive experience for our users. It makes more sense to me to show how to use the alert details page and the elements on the page to fix/triage issues than to simply document elements on the page.

[dedemorton]

@bmorelli25 FYI.... I need to bump this to the next sprint for some of the same reasons as the custom threshold alert details page:

• The original sizing for this work was inaccurate. The complexity here is that what's displayed on the page depends on the type of SLI that's selected. I am going to need to do more research and testing to figure out how to best document this page.
• All of the concepts around alerting are pretty new to me, so there's also a learning curve to overcome.
• This sprint is a short one for me.