[Logs] Extend number of fields used for resource field

[ruflin]

In Logs Explorer, the resource column is used to tell users where the log message was generated. The current list of fields that are taken into account can be found here. This issue is to discuss some additional fields. Each can can be implemented separately.

observer.name

In the context of network logs, the observer of the data is the data collector. In these scenarios, no host.name exist but an observer.name. This should be added as a fallback if no other fields exist.

Host/Cloud improvements

In case there is a host.name and we have the data of a cloud provider, it would be great to show the cloud icon as part of the host name field to make it clear it belongs to a cloud instance.

Further if there is a cloud region, it would be nice to see this also in the list of fields. I'm torn between cloud region and cloud availability zone on which one to show.

Orchestrator

If we have a service.name and orchestrator / kubernetes fields, for the host.name part we should show the kubernetes icon. Potentially for larger deployments, the addition of the orchestrator name to the list would be useful to directly understand which k8s cluster the data belongs to and filter on it.

[elasticmachine]

Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs)

[gbamparop]

In case there is a host.name and we have the data of a cloud provider, it would be great to show the cloud icon as part of the host name field to make it clear it belongs to a cloud instance.

Is host.name always going to be populated when cloud.provider exists?

Also, by default host.name is third in the list, after service.name and container.name so it's likely that the icon is not displayed in the default view.

Row height: Single

Row height: Auto fit

[ruflin]

host.name will normally be populated too. But I would prefer that we keep sticking to 1 row to have a good overview. Do we have some design alternatives to have icons visible but maybe not full text? The basic idea is: User looks at it, knows directly which service and where it runs without having to do much reading.

[gbamparop]

Agree, makes sense for all icons to be in the first row. They are only part of the service name in Figma. cc @isaclfreire

[gbamparop]

If we have a service.name and orchestrator / kubernetes fields, for the host.name part we should show the kubernetes icon.

Wouldn't it make sense to show both k8s and cloud provider icons in this case, like in APM?

[ruflin]

@gbamparop It would be great if we could show the combination to get the full picture.

[isaclfreire]

I think it depends on what kind of information is important to the user and it might not be the same for each resource shown everytime. For some resources the icon might be enough, for others the value could be a better indicator. It's all about how the dataset is populated (e.g. has multiple different services, or has only one service 'type/icon' but different names, etc).

Another thing to consider: back when we were actively working on virtual columns there were discussions around having generic icons for host.name, container.id or kubernetes.container. We can resume them back to differentiate the information. See below.

Plus, in some cases, truncation could come in handy to help resolve the row height problem. I think it's very hard to keep only 1 line height and would recommend we consider at least 2 as default (since 3 might be too much).

What about we define which fields are potentially 'icon-only', and which ones are 'value-oriented', and which are both so we can make sure to cover differente scenarios? I don't think we've went that far in the scenarios before.

cc @achyutjhunjhunwala

[ruflin]

The things that are icon only are Kubernetes, Cloud and potentially Otel? Some more? What if for the things that are icon only, it is combined with the first entry? So in case we have a service foo that reports otel data, running on k8s on AWS this entry has 4 icons? Then in the drop down, the details for all 4 entries are shown.