[Logs UI] Redirect Logs UI routes to Discover when serverless

[weltenwort]

📓 Summary

Since the Logs UI will not be the main log consumption UI when Kibana is run in observability-serverless mode, we want to reconfigure the client-side routes to redirect to a different UI in that case. Where exactly that UI will be located and how it can be linked to has not been decided, so we need to link to Discover for now.

✔️ Acceptance criteria

• There is a configuration option in the infra plugin, which switches the behavior of the client-side routes.
• When unset or set to the default value logs-ui, the routes behave as before and below changes don't have any effect.
• When set to the constant discover, the app routes of the Logs UI redirect to equivalent Discover views using locators:
  • When the Logs UI is configured to use an index name pattern, the redirect contains an equivalent ad-hoc data view.
  • When the Logs UI is configured to use a data view, the redirect contains its id.
  • The redirect sets the columns in discover to match the columns of the log view.
    • The field type columns are used as they are.
    • The timestamp type column is translated into a column showing the @timestamp field.
    • The message type column is translated into a column showing the message field.
• In the file config/serverless.oblt.yml the configuration option is set to discover.

💡 Implementation hints

• [serverless] split serverless config files #150616
• [config] mechanism to prevent internal configs from leaking to self-managed users #152395

[elasticmachine]

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

[tonyghiani]

Hey @weltenwort! Working on this issue, I've got a couple of questions:

• Which pages of Logs UI need to be redirected? Only the log stream page or also all the others (anomalies, settings…)? I’m wondering how they can set logs preferences if they can’t access the feature settings, do we want the user to fully manage the logs in the Discover view?
• Do we want to set a human-readable name for the ad-hoc data view or do we leave the index pattern as a name too?
• Do we want to pass also all the applied filters (if some exist) when redirecting to Discover?
• As the redirect requires knowing about the log view and the current dataView/indexPattern, the redirect feels less straightforward since the navigation is triggered while the logs app begins to load the router. Do we have any way to decouple the log view fetching from the state machine that holds it? Is it really necessary or we can leave the redirect as it is now?

[weltenwort]

To echo what we concluded on a different channel:

• only the stream page needs a redirect
• we can use the log view name for the ad-hoc data view
• let's not pass the filters for now
• let's perform the redirect as early as possible in the app init process

This is just for the record 📒 since you already applied this in your PR.

[tonyghiani]

• only the stream page needs a redirect

in this scenario, I'll then need to update the current PR logic, because doing the navigation at the app mount level is navigating to discover any page of the logs app. I'll find a way to update it keeping the navigation at the top level.

[weltenwort]

I think it's fine to redirect everything if it's easy. The stream page redirect would be the minimum, but anything extra is even better.

[jsoriano]

Hey @weltenwort @tonyghiani, taking a look to the differences between the different offerings, I found this new setting in the observability configuration for serverless. Out of curiosity, is there any reason to don't use the same setting in all serverless offerings?

[weltenwort]

Hey @jsoriano, that's a good question. I guess we didn't consider that the infra plugin would be enabled at all in other serverless project types. If that will be the case then that setting should be moved into a generic serverless configuration file.