[GS] Add Observability deep links to navigational search

[joshdover]

Meta issue: #72680

In #83380 we added support for applications to include a searchDeepLinks property on their core.application.register call which feeds into the navigational search feature.

Observability apps should add this property to add deep links for their key locations to search. In most cases, this should be adding an array with the name of the location and a URL path to the route in your app. See the documentation for this API for more info. Some things to consider:

• The title for each link should be localized
• The path for each link should be relative to your application's appRoute. Base path does not need to be included.
• If there are locations that are only conditionally available (for example, due to licensing or feature controls), you can utilize the appUpdater$ API. See the example in the Stack Management app.

New links to add

Logs

• Stream (same entry point as Logs app)
• Anomalies
• Categories
• Settings

Metrics

• Inventory (same entry point as Metrics app)
• Metrics Explorer
• Settings

APM

• Services (same entry point as APM app)
• Traces
• Service Map

Uptime

• Overview
• Settings

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[sorenlouv]

@joshdover This looks great! Can we use the appUpdater$ for adding deep links to dynamic content? So in APM's case we'd want to add deep links to the user's (micro)services. This is based on data in elasticsearch so we'd have to do a query first before registering them as deep links.

[joshdover]

@joshdover This looks great! Can we use the appUpdater$ for adding deep links to dynamic content? So in APM's case we'd want to add deep links to the user's (micro)services. This is based on data in elasticsearch so we'd have to do a query first before registering them as deep links.

Absolutely that should work, appUpdater$ is very generic and can be updated in any you see fit and search will adapt.

That said, we also need to consider how these non-link results are presented to the user. We have a similar issue open for adding non-SO user data to search (#74283) but there hasn't been much discussion on what that will actually look like. For the APM services use case, I personally see no problems with presenting a result that is formatted like APM / Services / <service name> with the APM application icon. cc @ryankeairns @alexfrancoeur

[joshdover]

One concern is adding more weight to the initial page load by adding another request to the Kibana backend + Elasticsearch. Another way we could accomplish this is by having the APM plugin register its own search result provider for services that will only be called on-demand when the user starts typing in search.

[sorenlouv]

Another way we could accomplish this is by having the APM plugin register its own search result provider for services that will only be called on-demand when the user starts typing in search.

We could definitely do that. However, if every app does this, won't search become slow since it'll have to perform search request per app - could be 50+ requests, right?

Another problem I see with async search result providers is that search results will either be ordered by whatever comes first (not great for relevancy) or ordered by priority meaning that results arriving later will push other results down causing a jumpy experience. Both approaches have their disadvantages.

In this specific case we want to help the user quickly find and navigate to a specific APM service. Since we don't expect APM services to change too frequently it's fine to cache the results for eg. 24 hours. So instead of searching on-demand (with search result providers) we could have a background job that daily registers them via appUpdater$.

WDYT?

[joshdover]

Since we don't expect APM services to change too frequently it's fine to cache the results for eg. 24 hours. So instead of searching on-demand (with search result providers) we could have a background job that daily registers them via appUpdater$.

The caching approach in general sounds good to me. I'm not sure if we should push these into search as application links though. It may be better to have a separate search provider that is completely sync (and uses the cache) so that these results can be displayed differently or ranked separately from 1st and 2nd order application links.

So in effect, this is really a UX question. Either approach should be easy to switch between though and using appUpdater$ today would be the easiest option. However, I do caution against us making frequent changes to how results are displayed or ranked since users may develop some 'muscle memory' and changing this often would create a frustrating experience.

[sorenlouv]

So in effect, this is really a UX question.

Agree!

It may be better to have a separate search provider that is completely sync (and uses the cache) so that these results can be displayed differently or ranked separately from 1st and 2nd order application links

I like the sounds of that. We are targeting this for 7.13 so perhaps by then there is something like this in place? If not we'll go with the current async approach.

[alexfrancoeur]

I do caution against us making frequent changes to how results are displayed or ranked since users may develop some 'muscle memory' and changing this often would create a frustrating experience

+1 on this. @sqren would it be possible to rope myself and / or @ryankeairns into any design discussions or issues related to the user experience? This would be more for visibility than anything. (cc: @thesmallestduck )

[sorenlouv]

@alexfrancoeur Sure. Right now we only have this issue which is slated for 7.13. Implementation hasn't started yet.

[joshdover]

I like the sounds of that. We are targeting this for 7.13 so perhaps by then there is something like this in place? If not we'll go with the current async approach.

Yes, any x-pack plugin may register custom providers with the global_search plugin. Documentation is available here: https://github.com/elastic/kibana/tree/master/x-pack/plugins/global_search#registering-custom-result-providers

It's an Observable-based API that can be leveraged however the consumer needs.

[joshdover]

Closing this for now since this was solved by #96135. This could be enhanced with more dynamic content, like APM services, in the future but the original request here has been solved.