Lens: Series with same names of different layers not distinguishable

[flash1293]

When creating an xy chart with multiple layers and split series which map to the same name (e.g. because a terms agg is used and both layers return the same terms), the chart is not indicating somehow which series belongs to which layer.

In the screenshot both layers produce jpg, css and png series, but they can't be mapped back to the datasource.

A possible solution would be to allow to name a layer and prepend its name to the series name.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[wylieconlon]

@flash1293 the example you've given doesn't look like a useful visualization, because you've built 2 identical queries and are trying to visualize them. Is there a better example?

Regardless of the example, your request for better naming is totally reasonable, but I'm trying to understand how important it is to make a change here.

[flash1293]

@wylieconlon I'm not sure how often this comes up in real-world scenarios. IMHO it's plausible though - when overlaying data from multiple sources in the same chart your serie names can collide very easily as you are very likely working within a single domain.

A fictional example:
I have web log data and auto detected events from a siem I want to correlate (think logs-* index pattern and security-events-* index pattern). I create two layers to see them over time overlayed. Then I want to drill down by country (of traffic and security events) and add a split series aggregation to both layers splitting by their respective iso encoded country fields. Now I'm getting series with the same name from both layers and I can't differentiate between them anymore.

[wylieconlon]

Found a real-world example where I could compare the behavior with layers vs two y-axis:

Layers:

Two Y-axis:

[ghudgins]

idea: name a layer and pre-append this to series

[flash1293]

+1 #136069

[gr0vity-dev]

Does any workaround for this exist?
I'm comfortable with exporting my dashboard, modifying the json and reimproting if necessary.

I have a cluster of 5 nodes that log the exact same metrics, except they have a custom "_node_name" tag attached to each log.
Here an example :
{ "_node_name" : "node1" , "valueA" : 1 , "valueB" : 2 , "valueC" :3 , .... }
{ "_node_name" : "node2" , "valueA" : 9 , "valueB" :8 , "valueC" :7 , .... }
...

In the first visualisation I plot "valueA" broken down by "_node_name"
In the second visualisation I plot "valueB" broken down by "_node_name"

[flash1293]

@MichaelMarcialis I started working on this but I realized I need design support. Could you assist with the following questions?

• We talked about having a context menu per layer, but where should the user enter the layer name? Have a "Set layer name" action in the context menu which opens a modal? Something else?
• Where to show the layer name in the UI? I don't immediately see a good place for it:

[MichaelMarcialis]

@flash1293: Forgive me, as this is the first time I'm seeing this issue and likely don't have the full history of the decisions made. Out of curiosity, why was it determined that the solution to this issue should be to allow users to add a custom name to the visualization layers? Instead, could we simply use the related dimension's name as the string used to prepend/append to the duplicative terms to better identify where they originating from? I imagine this would be a much lighter lift on the engineering side and also requires less work on the part of the user.

So given your original example, could we not simply use the names provided to the breakdown dimensions to prepend/append to the duplicative terms?

[flash1293]

Good idea @MichaelMarcialis - Would you imagine this as a setting of the breakdown dimension or an automatic thing as soon as there are multiple layers using breakdowns?

[MichaelMarcialis]

Good idea @MichaelMarcialis - Would you imagine this as a setting of the breakdown dimension or an automatic thing as soon as there are multiple layers using breakdowns?

My first instinct is to say that applying the prepend/append automatically as soon as multiple layer breakdowns are in play is probably the most user-friendly approach. However, I'll defer to you and @ghudgins if there are some cases that I'm not considering where it wouldn't be ideal.