[Log Explorer] Log Flyout highlight sections

[tonyghiani]

📓 Summary

🛑 - Pending PR merge #170107
🛑 - Pending PR merge #169501

To provide better insights on a specific log detail, we want to add highlight sections for those considered the most useful fields.

🎨 Design

• Figma design

✔️ Acceptance criteria

• Should display the highlights as part of a unique section.
• Each highlight...
  • should be able to be compressed, storing this preference in the browser storage.
  • should associate a human-readable label to each displayed field detail.
  • should be hidden if no fields are available for that specific highlight (e.g. missing Service and Agent Name fields, the Service highlight is not displayed)
  • should have available actions to filter the selection by a specific field value
• Should display a Service highlight with service.name, trace.id and agent.name fields.
• Should display an Infrastructure highlight with host.name, orchestrator.cluster.name and orchestrator.resource.id fields.
• Should display a Cloud highlight with cloud.provider, cloud.region, cloud.availability_zone, cloud.project.id and cloud.instance.id fields.
• Should display an Other highlight with log.file.path, data_stream.namespace and data_stream.dataset fields.

💡 Implementation hints

All the above-mentioned field values should come with the currently opened document from the customization extension point when #169394 is implemented.

[achyutjhunjhunwala]

@tonyghiani Couple of questions

1. Each Highlight - should be able to be compressed, storing this preference in the browser storage.

What does this mean ? Can you explain this a bit more

2. should have available actions to filter the selection by a specific field value

Do we already have a component which can be reused here. My understanding is, we will need to have this text wrapped in a component which on hover will open a popover which will show the Add/Remove filter icon ?

[tonyghiani]

Sure, let me clarify these points

1. Each Highlight - should be able to be compressed, storing this preference in the browser storage.

Say the user is presented with all the sections Service, Infrastructure, Cloud, Other expanded and displaying data.
A particular client might not be interested in a specific highlight section, and since it's just noise on the screen, (s)he compresses it.
As a user, I would expect that moving on next/previous log entries my preference is respected, so that I can focus only on the details I need.
@ruflin @isaclfreire do you have any opinion about this?

2. should have available actions to filter the selection by a specific field value
   Do we already have a component which can be reused here. My understanding is, we will need to have this text wrapped in a component which on hover will open a popover which will show the Add/Remove filter icon ?

Correct, it should behave in a way that allows the user to over a field and get the same actions they would get from the fields table.

The design shows how we should render the actions in a popover (the following screenshot is taken from an old version of the highlight design, please focus only on the actions popover):

We should look if there is an existing component with this design or if we need to implement it. The actions provided by the extension point should help to set the interactions with these popover CTAs.

[achyutjhunjhunwala]

@tonyghiani Thank you for answering them

1. I see your point now. After closely looking at the designs, i see these highlights needs to be in an accordion. The word compressed confused me, i believe you meant collapsed. I would avoid any sort of session/local storage for this and would see if this can be implemented with local states.

2. I will investigate on how to handle the popover thing. Yes the actions already have the setfilter function which we can use.

[tonyghiani]

I would avoid any sort of session/local storage for this and would see if this can be implemented with local states.

Mmm how would you do that? Session/Local storage is typically used for storing user preferences, handling this locally would make the state management more complex, while retrieving the preference from a storage source would allow to scope of the state on a per-section basis.

All of this is necessary only if my assumption is correct and we want to save these user preferences, otherwise, it won't be necessary.

[achyutjhunjhunwala]

All of this is necessary only if my assumption is correct and we want to save these user preferences, otherwise, it won't be necessary.

Exactly my point. Do we really want to save them as a User Preference ?

[tonyghiani]

Exactly my point. Do we really want to save them as a User Preference?

Let's speak the topic with the team the get a wider band of opinions about this.

[ruflin]

@ruflin @isaclfreire do you have any opinion about this? -> collapsing

It might be more complex then this. If the user looks as a service log, the infrastructure part might be less relevant and the user collapses it. Now the user looks at an infra log and no service part exists and everything is collapsed, that seems surprising.

To simplify things, I would not offer any collapsing at all. Lets rather focus on only showing the most important fields that are always relevant and not give a user the choice to collapse (for now).

There is an additional bit here which is not part of the design yet but we need to talk about eventually. For cloud or k8s, there are lots of additional fields that the users might be interested in but we should never show by default. Still, user should be able to see these fields in an easy way together with the other k8s fields after doings something in this block. But again, this would not be persisted.

[achyutjhunjhunwala]

@ruflin I have 3 questions around the new design

1. Service -> Trace field - What is the underlying field here. It looks like a transaction.name field to me from the designs, and Transaction.name seems to be a APM data, will it be present in Logs ?
2. Others -> Shipper - Same, what is the underlying field here. I saw comments on Figma and is not confused between agent.name and host.name ?
3. Infrastructure -> Orchestrator Cluster ID, Is this field really an id or name ? Seem like this orchestrator.cluster.name

[ruflin]

General comment: Let's not be picky about the fields at the moment, the most important part is the base framework. If we are not sure about a field, lets kick it out.

More specific on the three topics above:

• 1. I think the goal was trace.id for the linking @gbamparop had some good references on what to use. We can also skip it for now
• 2. Shipper = Agent. I should be agent.name
• 3: We should show the orchestrator.cluster.name. It would be nice if in the drop down users could also filter based on the id

Lets get a first version in and then iterate on the field. Please don't build special code for now into the different fields to make sure we can still easily iterate on it afterwards.

[gbamparop]

1. I think the goal was trace.id for the linking @gbamparop had some good references on what to use. We can also skip it for now

I agree that if it's not straightforward we can iterate on it later. The APM identifiers which are currently used for logs correlation can be found here. Transaction name doesn't seem to be available but it's a required url param in the APM transaction details page that contains the trace waterfall. Another option would be to link to trace explorer which accepts traceId and transactionId params. The drawback in this case is that trace explorer can be disabled by users through Kibana settings.