[APM] Linking to Infra and Logging UIs

[makwarth]

This is a new implementation issue for #26326 and what we discussed around 6.5.
Handy: 6.5 implementation issue #23315 and the removal issue #24562

Motivation

We're bringing back the integration links in 6.6.

For the links to be useful, the logs, metrics and APM data needs to have the appropriate fields in their documents, for example container.id or kubernetes.pod.id.

We're working to make it easier to set things up such that fields are added and the links are useful.
For example, with elastic/apm#22 container ID will automatically be added if the agent runs in a container. With elastic/apm#21 APM agent data will have kubernetes fields as well.

For when these links result in jumping to another solution with no results (due to the above complications) we'll update the no page-message to include a troubleshooting guide.

Update: We've decided to deactivate any links that links to a null value. We need some way of letting the user know why some links are greyed out. (e.g. tooltip with link to docs)

Cross-solution links

• Bring back links in the transaction sample header
• Implement links in the error occurrence header (not required in this iteration)
• Don't implement these links for RUM services

Link	Description
"[icon] Show trace logs"	link to logs UI filtered for time and trace.id
"[icon] Show pod logs"	link to logs UI filtered for time and kubeternetes.pod.uid
"[icon] Show container logs"	link to logs UI filtered for time and container.id
"[icon] Show host logs"	link to logs UI filtered for time and host.name
"[icon] Show pod metrics"	links to infra UI filtered for time and kubeternetes.pod.uid
"[icon] Show container metrics"	links to infra UI filtered for time and container.id
"[icon] Show host metrics"	link to infra UI filtered for time and host.name

[icon]: Solution icon of app that we're linking to.
Deep-linking URLs: #23315 (comment)

Troubleshooting link

Links from Infra and Logging will drop into /app/apm#/services/ with a trace.id : query, so we should add our troubleshooting link here.

• Add troubleshooting docs link to Services list "no result" message (Example)

[elasticmachine]

Pinging @elastic/apm-ui

[jasonrhodes]

@makwarth we had a question about the logic for showing which link? Do we just show any of the links above if there is data for the associated value present and hide otherwise, or are there some links that should not be shown for other reasons (e.g. don't show the host logs link if kubernetes.pod.uid is found, or things of that nature)?

[roncohen]

an example: if there's no kubeternetes.pod.uid on a trace, it might be awkward to link to logs filtered by kubeternetes.pod.uid:""

[makwarth]

This ended up being a longer reply that anticipated. Here goes:

I think it's important that the links are always shown, so that they don't "randomly" disappear. I agree with the concern and it's not a great solution to knowingly link to a "no results" page. However, this is generally how Kibana (and other tools) work already. For example, the time picker won't indicate, if there's data or not before navigating to a range. Similarly, visualize won't stop you from doing an aggregation that leads to no results. Showing good documentation on "no results" pages is a standard and scalable solution, imo.

Having said all that, we could look into greying links out, if they don't link to a meaningful value. Question then becomes: How do we inform the user about why some links are greyed out? We'd need a tooltip, or similar, with copy and/or a link to documentation. If possible, having greyed out links with good tooltips is probably the ideal solution, but it also requires more work and maintenance. If this is doable before 6.6, I'm all for upping the polish on this issue, but I'm also good with shipping as is and iterating after.

[sorenlouv]

I'm worried the user will very quickly lose faith in the feature, if they get used to seeing "No results" when clicking a link. I therefore think greying out the links is a must-have in the first iteration - it also shouldn't be difficult to add.

[makwarth]

How difficult will it be to detect "meaningful value"? How likely is it that e.g. container.id has a value, but it's the incorrect value?

[roncohen]

generally, if there's a value we should show the link. As far as I can tell, there's little chance of the data being there but incorrect.

[makwarth]

Ok, that's easier than I expected 👍 I'll update the description