[Performance] Report scale dimensions for service-map and hosts

[kpatticha]

closes https://github.com/elastic/observability-dev/issues/3777

Summary

This PR provides scale dimensions for the service map and infra host pages without introducing any additional requests.

Global Service Map and Per-service APM Service Map

Metric	Description
num_of_nodes	Total number of discovered nodes (services + dependenies
num_of_traces	Total number of traces

Infra

Metric	Description	default
num_of_hosts	Total number of hosts
max_hosts_per_page	Maximum number of host returne 50/100/500	100

Page	Screenshot
Global Service Map
Per-service APM Service Map
Infra	!

How to test

• Open any of the above pages
• In the network tab, look for kibana:plugin_render_time

[elasticmachine]

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

[jennypavlova]

LGTM
I have one question about the services count: I see in the service map different numbers in the count (it's services + dependency) :

The trace count is different compared to the traces page (23 traces are shown on the service map tracking and only 13 traces are shown on the traces page) :

Maybe there are some filters or other logic I am not aware of but decided to share that anyway to make sure I understand how we track it 😅 (and make sure that it's not an issue)

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: c28ec6e

Failed CI Steps

• Post-Build

Metrics [docs]

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

History

• 💔 Build #264338 failed d7ff98a

[kpatticha]

LGTM I have one question about the services count: I see in the service map different numbers in the count (it's services + dependency) :

Good catch, thanks for checking. The count reflects the total number of nodes (services + dependencies) so the servicesCount field name is misleading. Renaming it to nodesCount / nodeCount would be more accurate as I believe it will be useful to have this dimension. wdyt?

The trace count is different compared to the traces page (23 traces are shown on the service map tracking and only 13 traces are shown on the traces page) :

Maybe there are some filters or other logic I am not aware of but decided to share that anyway to make sure I understand how we track it 😅 (and make sure that it's not an issue)

Yes, the top traces check if it's the root transaction so it's expected to be a lower nunber.

[jennypavlova]

@kpatticha Thank you for explaining!

The count reflects the total number of nodes (services + dependencies) so the servicesCount field name is misleading. Renaming it to nodesCount / nodeCount would be more accurate as I believe it will be useful to have this dimension. wdyt?

I like your suggestion as node will be easier to understand in the context of a service map in this case (as you said we count both services + dependencies so I think nodeCount is good)

[weltenwort]

LGTM from a logs-ux codeowner perspective

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/12672383328

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 205607

Questions ?

Please refer to the Backport tool documentation