[Explorer] Add Explorer app locator

[weltenwort]

📓 Summary

In order to programmatically navigate to the new observability log explorer app, we want to add a locator, that supports passing data specific in a type-safe way.

• 🛑 blocked by: [Log Explorer] Convert log explorer profile into standalone app #164493
• 🛑 blocked by: [Logs+] Implement Logs Dataset selector #159907
• 🛑 blocked by: [Infra] Disable infra plugin in serverless projects #165289

✔️ Acceptance criteria

• There is a locator in the plugin x-pack/plugins/observability_log_explorer, that navigates to the observability log explorer app, which...
  • accepts properties to specify the integration name and the data stream name
  • optionally accepts a sub-set of properties of the Discover locator:
    • timeRange
    • refreshInterval
    • filters
    • query
    • columns
    • sort
• If the observability_log_explorer plugin is enabled, the on-boarding flows for system logs and application logs use the locator to navigate to the observability log explorer app via the "Explore Logs" Button at the end.
• Otherwise it navigates to Discover with an appropriate data view and filters. (which is the case for the serverless security project type)
• If the infra plugin is enabled, the log links in APM use the infra locators as before.
• If the infra plugin is disabled, the log links in APM use the new observability_log_explorer locator (instead of completely hiding the link as implemented in [Infra] Disable infra plugin in serverless projects #165289).

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[isaclfreire]

To answer @mohamedhamed-ahmed comment in the previous issue:

The problem is in Pending, and Failed states.
I guess it would make sense that the button is disabled while we are at the Pending state and only enable it once we land on either one of the other 2 states.
The question is Where should we actually navigate to if the status is Failed, if we should allow navigation at all.

I agree with the first proposal: the button is disabled while we are at pending - it's a transitional state - and then it becomes active in both cases: if the install is successful or not. In my opinion, although the integration install failed, users should not be prevented to get to Logs Explorer, to see other logs they might have or even just to see an empty state, but browse the app.

[mohamedhamed-ahmed]

although the integration install failed, users should not be prevented to get to Logs Explorer

@isaclfreire What should we navigate to in this case? should we select the logs-* in this case or something else?

[isaclfreire]

logs-* LGTM. @ruflin wdyt? do you have any concerns?

To be more specific, whenever the installation fails, we could change the CTA of the button from 'Explore logs' to something like 'Open Logs Explorer' with the primary blue color. Or just anything really that still takes them to their logs, but is not strictly related to the success/failure of the process

[ruflin]

logs-*-* SGTM. I assume logs-*-* is our default and not logs-*.

[weltenwort]

We mean the "all logs" selection mode, right? The log explorer app locator shouldn't have to know about the internals.

[yngrdyn]

What should we navigate to in this case?

Could we just go to an specific dataset? In this case we know what are the system integration datasets, even though user couldn't install the integration probably the logs are arriving there

[mohamedhamed-ahmed]

We mean the "all logs" selection mode, right? The log explorer app locator shouldn't have to know about the internals.

Yes this is what I meant, using the all datasets locator which selects All Logs option from the dataset selector.

Could we just go to an specific dataset? In this case we know what are the system integration datasets, even though user couldn't install the integration probably the logs are arriving there

I think in case of failures we will be navigating to the above mentioned selection.

@yngrdyn we might need to update the Explore Logs button in this case, so that its aware of the integration installation status, so that we are able to modify the navigation in case of failures, or disabling the button in case of pending state.

[yngrdyn]

@yngrdyn we might need to update the Explore Logs button in this case, so that its aware of the integration installation status, so that we are able to modify the navigation in case of failures, or disabling the button in case of pending state.

Should we create a new issue? or just fix this in the context of this one?

[mohamedhamed-ahmed]

Should we create a new issue? or just fix this in the context of this one?

I would suggest maybe creating a separate issue, the scope of this PR has many modifications already which will be pushed soon. But I am fine if you think we should do it here.

[yngrdyn]

Let's tackle this in a separate issue then.

Feel free to comment there or complete the description @isaclfreire or @mohamedhamed-ahmed

[ruflin]

accepts properties to specify the integration name and the data stream name

Assuming we expand the selection to hosts/services in the futere, I assume we will need to expand this eventually?

[weltenwort]

Yes, we've decided to rather have several small and focused locators for different cases. For now we'll have locators for single selection and "all" selection, but can easily add more later for further selection modes.