Logs flyout enhancements for use on APM service logs view

[cyrille-leclerc]

Describe the feature:

When troubleshooting and viewing a log entry from the "Log Entry Details" flyout of the Logs App, we want:

• [APM Service Logs] Show flyout in LogsEmbeddable #111325
• [APM Service Logs] Show link to log line in context in log entry flyout #129609
• [APM Service Logs] Link to "open in Kibana" in log entry detail flyout #129610
• [APM Service Logs] Show _id field on log entry flyout #129607
• [APM Service Logs] Allow navigation between log lines on log entry flyout #129615
• [APM Service Logs] View log entry details as a table or JSON #129614

Example of Kibana Discover flyout (v8.1, new display)

[elasticmachine]

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

[weltenwort]

@cyrille-leclerc, thanks for illustrating the changes! I'd like to ask some questions to increase the clarity further:

Permalink to share, via slack or via a bug ticket, the hyperlink to visualize the log entry

Should the link just navigate to the log stream at the specific time or should it also open the fly-out? We don't yet have a stable link schema for the latter, but it could be added.

Link to Kibana Discover in the "Investigate" drop down

Since Discover requires an underlying data view this would only be available if the log source was configured to use a data view itself. Would that be acceptable?

Easy access to the _id field

The id is shown in the title of the flyout. What would make it "easier" to access if it was added to the table?

[cyrille-leclerc]

Thank you very much @weltenwort for your detailed review of my requests.

Permalink to share, via slack or via a bug ticket, the hyperlink to visualize the log entry

Should the link just navigate to the log stream at the specific time or should it also open the fly-out? We don't yet have a stable link schema for the latter, but it could be added.

I would like to link to a specific log message with "expanded view on this details". Today the way to visualize the details of a log message is the flyout so it would ideally be a link to the opened flyout.

I am not a huge fan of the flyout because it prevents from inspecting multiple log lines in parallel. I have the same problem in our trace explorer, I would prefer our GUI to expand a fragment of the underlying screen rather than introducing a modal flyout.

Link to Kibana Discover in the "Investigate" drop down

Since Discover requires an underlying data view this would only be available if the log source was configured to use a data view itself. Would that be acceptable?

I think so because configuring our logs explorer with a data view will be our recommended setup. Longer term, we should aim at supporting the same selection of underlying dataset in all screens. I think the ongoing search unification initiative (cc @jasonrhodes and @smith ) is our solution to make our GUIS more consistent.
If we disable "open in Discover" for "non data view settings", I would like to have a clear explanation provided to the user (maybe feature is greyed with online documentation explaining why I can't benefit of it)

Easy access to the _id field

The id is shown in the title of the flyout. What would make it "easier" to access if it was added to the table?

I was searching for the _idfield in the list of fields, the same way the _id field is listed with other fields in the Kibana Discover flyout.

By the way, why don't we reuse the Kibana Discover Flyout?

[weltenwort]

I would like to link to a specific log message with "expanded view on this details". Today the way to visualize the details of a log message is the flyout so it would ideally be a link to the opened flyout.

I am not a huge fan of the flyout because it prevents from inspecting multiple log lines in parallel. I have the same problem in our trace explorer, I would prefer our GUI to expand a fragment of the underlying screen rather than introducing a modal flyout.

Yes, it's quite obtrusive. But that change would warrant a separate design effort.

[...] configuring our logs explorer with a data view will be our recommended setup. Longer term, we should aim at supporting the same selection of underlying dataset in all screens. I think the ongoing search unification initiative (cc @jasonrhodes and @smith ) is our solution to make our GUIS more consistent. If we disable "open in Discover" for "non data view settings", I would like to have a clear explanation provided to the user (maybe feature is greyed with online documentation explaining why I can't benefit of it)

Yes, that sounds good.

I was searching for the _idfield in the list of fields, the same way the _id field is listed with other fields in the Kibana Discover flyout.

I see. They must be explicitly merging the meta fields into the fly-out's field list. We could do that as well.

By the way, why don't we reuse the Kibana Discover Flyout?

Because our fly-out is older than Discover's. Until Discover recently changed their rendering to the data grid they used to expand the details of the documents inline. I don't know if it is written in a way that we can re-use it and add special elements like the links to APM and Uptime.

[cyrille-leclerc]

Please note that I added the following enhancements to this umbrella ticket:

• Navigation "|< < > >|" on log line details similar to Kibana Discover
• Switch visualization of log line details between "Table" and "JSON" similar to Kibana Discover

Flyout versus inlined details
Yes, it's quite obtrusive. But that change would warrant a separate design effort.

💯 replacing the flyout by inlined details would be a big effort, broader than just this use case, not to be worked on for the moment but hopefully food for thoughts for our product design team (cc @katefarrar )

[cyrille-leclerc]

@weltenwort as discussed, I broke down this umbrella enhancement request in 5 sub tickets.
@katefarrar @weltenwort please tell me if the problems to solve are refined enough. Please feel free to evolve the UX the want you want, my "mockups" are just intended to describe the idea.

[weltenwort]

nice, thank you! I'll ask any further refining questions on the individual issues

[smith]

Closing this in favor of #134412.