[APM] Service overview initial table query

[smith]

(Part of the new APM service overview. See #81135 for more.)

Determine the initial query or queries to populate the data on the overview page when it's first loaded, either separately per-table or in a single query to populate some or all tables.

The larger latency and "side" charts use their own separate queries.

Create the tables needed for this initial load and their loading and empty states.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[dgieselaar]

@smith can you specify what charts exactly?

[smith]

@dgieselaar #81135 shows all of the charts and tables used on the page.

[dgieselaar]

@smith Yes, but this only covers some. Can you clarify which one? Do you mean the four tables on the right? Probably, but want to be sure.

[smith]

@dgieselaar Yes we need to determine which queries we're going to use to load the data, including the sparklines, into the tables on the right. "The larger latency and "side" charts use their own separate queries." The charts are using separate queries.

This ticket is to figure out the "best" way to load the data into the tables on the page. Some options:

• Load the list of errors and transactions in one query; load additional data for the other columns and sparklines in a second query
• Load all four tables and their data in a single query
• Make one query for all the data and sparklines in each table

We would like to have a useful page as soon as possible, so loading additional data with subsequent queries, or breaking the queries up in other ways, are different ways to do this.

[dgieselaar]

I think we should fetch per component, but not add any parallelisation in each request, like we do in the service inventory page. Given the many components on this page, I would be worried about having too many connections to Elasticsearch. On the flip side, loading all tables in one request might delay showing any components longer than needed. We can optimize queries later.

For the transactions table, we can use a similar strategy as we have on the service inventory page, but without the parallelisation, and broken down by transaction.name instead of service.name.

For the errors table, if we want to show "First seen", we need to aggregate over all the error documents, not just those available in the given time range. Or, we could have an upper bounds but not a lower bounds. In this case we can use a min aggregation on @timestamp. Perhaps a strategy here is to load the error groups first, without first seen, and then do a second request with just the error groups that are visible in the component. We should look into telemetry to get a feel of how many errors the average user has, compared to transactions. If it's significantly lower, aggregating over (almost) all the error documents might not be an issue.

For the dependencies table, I'll defer to @ogupte in #81120.

For the instances table, it's similar to the transactions table, but will include metrics.

[dgieselaar]

I have not written out the queries because my assumption is that this should be straightforward given the examples we have in the codebase of similar queries. Happy to help out if it's still needed.