[SLO] paginated api for groups

[mgiota]

Fixes #174330

This PR creates the paginated API for groups, without summary for now. Summary data will come in a follow up PR

[apmmachine]

🤖 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!)

[kdelemme]

Just one note on the api versioning. Otherwise LGTM

[kdelemme]

Since this is behind a feature flag, it's fine to start with the result being a Record<group, number of element in group> but when we introduce more stats in the response, we'll have to change the results to either an array or a Record<group, Stat Object>.

[mgiota]

Yep definitely the type will change when we introduce a) the stats and b) I guess when we introduce more group by options. So it will be more like:

{
"by_tags": {
   "test": {
       total: 5,
       worstValue: ...
       ...
     },
  },
 "by_status": {
     "healthy": StatsObject,
     "violated": StatsObject
  }
},
"by_sli_indicator": {
...
}

Is it fine to keep it like this for now? Once this is merged, I will work on the summary stats, so this change very soon

[kdelemme]

I'm not sure returning all the group options (by tags, by indicator, by sttus_ at once is ideal since you'll need to handle pagination within each, and also based on the API input parameter, we explicitly ask for the group we want, i.e. groupBy: groupBySchema
I'd imagine the API being something like:

> Request
GET /api/observability/slos/groups?page=2&perPage=10&groupBy=tags
< Response
{
  total: 13
  page: 2
  perPage: 10,
  results: [
    { group: "tag-value-ccc", stats: { healthy: 82, violated: 1, degrading: 3, total: 86  } },
    { group: "tag-value-aaa", stats: { healthy: 4, violated: 0, degrading: 0, total: 4  } },
    { group: "tag-value-bbb", stats: { healthy: 0, violated: 10, degrading: 0, total: 10  } },
  ]
}

[mgiota]

Ok so in case of grouping by status for example, you say we would still have the same response like this:

> Request
GET /api/observability/slos/groups?page=2&perPage=10&groupBy=status
< Response
{
  total: 2
  page: 1
  perPage: 10,
  results: [
    { group: "healthy", stats: { healthy: 82, violated: 0, degrading: 0, total: 82  } },
    { group: "violated", stats: { healthy: 0, violated: 10, degrading: 0, total: 10  } },
  ]
}

[mgiota]

Yep indeed the API accepts groupBySchema. At the moment I don't make use of it, but eventually we will as part of #174329

[kdelemme]

Correct. For status groups the stats are not very useful (except the total) but as we add more stats they will make sense.

[elasticmachine]

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

[mgiota]

@shahzad31 You recommended to fetch all tags in one terms aggregation and still have the UI pagination. How would I do this? I tried to remove the bucket_sort aggregation, but going to the next page didn't work well for me. It showed me the same tags with 1st page. Can you be more specific how you would do this?

[mgiota]

Oh I see I think I know what you mean. Use slice to display the items I need to show based on the active page

[mgiota]

@elasticmachine merge upstream

[mgiota]

@elasticmachine merge upstream

[kibana-ci]

💔 Build Failed

• Buildkite Build
• Commit: 6146ada579d857cdfec1843ff6b045101157aeb1
• Interpreting CI Failures

Failed CI Steps

• FTR Configs #79
• Post-Build

Metrics [docs]

‼️ ERROR: no builds found for mergeBase sha [48642b1]

History

• 💔 Build #188650 failed 01a6b62037a33ce2b515ca797aef13eef4c8988a
• 💔 Build #188636 failed 6146ada579d857cdfec1843ff6b045101157aeb1

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

cc @mgiota

[kdelemme]

Let's iterate on the API response shape in a follow-up PRs

[mgiota]

Ok cool I'm merging this one and will continue with the summary data