Kibana: Discover doesn't show field aliases

[bhavyarm]

Kibana version: 6.4.0 BC2

Elasticsearch version: 6.4.0 BC2

Server OS version: darwin_x86_64

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from staging

Describe the bug: Discover doesn't display field aliases in the side bar or in the results except for timestamp alias.

ES document for field aliases: https://www.elastic.co/guide/en/elasticsearch/reference/6.4/alias.html

ES issue: https://github.com/elastic/elasticsearch/issues/23714

Please note, you can create scripted field using them and they show up, you can also filter on them - they show up.

Steps to reproduce:

1. Add field alias for logstash data in loading data into Kibana (I am adding my mapping)
2. Create index pattern in Kibana with timestamp alias field
3. You can view the data in discover, create scripted fields, use them in filters and also visualizations using alias.
4. But they don't show up in side bar or in the results

cc @LeeDr / @AlonaNadler / @alexfrancoeur

mapping_text.txt

[bhavyarm]

Same results with non-time series data.

[alexfrancoeur]

@bhavyarm are the field aliases showed in the document itself? I'm guessing not but want to confirm. I would think this would be considered a blocking bug, no? Field aliases are expected to work as any other field. There should be support in the query bar, KQL and available to configure in visualize, just as normal fields.

cc: @elastic/kibana-discovery

[bhavyarm]

@alexfrancoeur No. They didn't show in the documents or results because we display only source in Discover. Alias for timestamp showed up in the sidebar because I used it as my timefield.
But they show up for visualizations, filters, scripted fields.

[ruflin]

I opened an issue here with a proposal how we can potentially solve / improve this problem: https://github.com/elastic/kibana/issues/28570

[DmitryLanda]

Is there are any workarround for it?

[LeeDr]

@DmitryLanda can you be more specific? The original description says;

Please note, you can create scripted field using them and they show up, you can also filter on them - they show up.

Did you try that? Need help with that? If yes, it might be best to post your specific question on https://discuss.elastic.co/c/kibana

[cwurm]

But they show up for visualizations, filters, scripted fields.

Unfortunately, they also don't show up in saved searches, including those embedded in dashboards.

I would think this would be considered a blocking bug, no? Field aliases are expected to work as any other field. There should be support in the query bar, KQL and available to configure in visualize, just as normal fields.

@alexfrancoeur I would have expected aliases to work exactly like normal fields, too. If they're not shown in Discover or saved searches in dashboards that partially defeats the purpose of using them for backwards and forwards compatibility, e.g. in Beats. They are not fully compatible. A saved search is the only way to display a non-aggregated list of documents in Kibana, and that aliases are not shown in those is a significant limitation. It feels like a bug or regression.

It leads to weird situations, like seeing 5 fields suricata.eve.alert.[category|gid|rev|signature|signature_id] in one place but not suricata.eve.alert.action because it is aliased to event.outcome.

Any chance we can get this addressed soon? We're not using aliases a lot in 6.x, but in 7.x this will be quite an issue, e.g. filebeat-* will have 30+ aliases.

[AlonaNadler]

@cwurm we are aware this is the existing behavior, currently, you can search by the field alias name, KQLalso supports field aliases, and autocomplete suggest field aliases, our main gap ATM is with the results showing the source so the field aliases do not appear in the results. We raised this as a concern in regards to ECS a few months ago but we were told beats will not be heavily depended on as part of the upgrade from 6.x to 7.0 so it wasn't prioritized high on our list, let's understand the implications and evaluate again if you think it is needed pressing

[ruflin]

From an ECS perspective I think it's not super urgent related to the migration but it would be good to put it (for example https://github.com/elastic/kibana/issues/28570) on the near term roadmap. The reason is that I expect that the alias usage not only internally but also by external users is going to increase because of ECS. Users will want to map their own data to ECS but keep the original fields or have the original fields in ECS and alias from the old fields.

ECS just went GA today (https://github.com/elastic/ecs/releases/tag/v1.0.0) so I hope also adoption is going to increase.

[timroes]

I am not sure if I get how aliases should exactly behave in Discover. So one thing I read is that we would like them to show up in the field list, so users see actually both. I assume we also want to highlight the alias somehow in the list.

Are there some desires to handle field aliases somehow in the discover table itself, and if so how?

[AlonaNadler]

The main pain point today is if field a has alias new_name users can search in the search bar using the alias new_name:foo Discover returns results, but the new_name field is not in the results, instead users will see a which they will need to know it is what's behind new_name field

my suggestion:

• If a field has a single alias it takes precedence over the original field name, as a result, it shows up on the left side nav field list, and in the document/discover table itself instead of the original field name

if there are multiple aliases for the same single field (less common) we can do few things

• duplicate the fields on the left side and so every alias will be there
• have an indicator next to a field and show all the aliases names
• show up in the results as the aliases (will show up multiple times, with each aliases)

[timroes]

I am wondering if we need this behavior only in Discover or if that shouldn't be a more centralized behavior. An index pattern already has the possibility to have an displayName for each field, that can then consumed by every application instead just discover.

My suggestion to simulate the behavior @AlonaNadler described above, but on the index pattern level:

• Make the user able to specify a custom name per field in the index pattern management section.
• If there only is one field alias for a field, use that alias by default as the custom name for the field (the user could always change it to whatever they want).
• If there are multiple field aliases, maybe leave it as the field name, but in the index pattern management UI give the user the possibility to quickly select one of the aliases as a custom field name (or specify their own).

That way we would actually be able to a) use field aliases all across Kibana not just Discover, b) wouldn't even be limited to field aliases, but users could also completely rename a field, to give it a more meaningful name for their users (and since an index pattern is Space based, they could give different target audiences different field names targeted better to them), and c) would still have some kind of "default" behavior for only one alias so it's used automatically.

If you think that would also be a feasible idea, I would close this issue here, and open another one for the index pattern enhancement.

[AlonaNadler]

I like your suggestion @timroes, it will be more friednly to do it from the index pattern page and configure the default field name.

The only drawback I can think of is that aliases are done on the index level and index patterns are per space, which might make it tedious to change the index pattern in each space, that operation will improve though with a copy to space capability coming soon

[LeeDr]

An index pattern already has the possibility to have an displayName for each field, that can then consumed by every application instead just discover.

@timroes where is that ^? I don't see it on 7.4.0.

I would suggest we start with the simplest approach for Discover.

• show field aliases and the original fields in Discover the same. No need to highlight that one is an alias. Showing that they are aliases can be added later if we get that kind of feedback.
• ideally the alias should work just like the real field (be queryable, filterable, and be able to be put in the doc table in discover)

[timroes]

@LeeDr sorry for the confusion, I meant it technically has the possibility to have a separate display name. We currently don't have a UI to let the user configure that. That would be part of my suggestion giving them a UI to let the name configure. I am also a bit concerned putting original field AND alias in the the table, since I see how this easily might cause more confusion than actually help clarifying it (despite the problem that this is technically not easily solveable, since the alias itself is not part of the _source that we are showing, so it's a way more complex approach then actually aliasing the field display names :D)

[mbarretta]

What if the default behavior for the displayName was to the ES field alias?

[felix-lessoer]

@timroes If you say the displayName is technically possible, but not via UI. Is there a way to put this into the API call?

[edmarmoretti]

This error also occurs in version 7.7 of Kibana. Values ​​are not shown when the column is mapped as "alias".

[felix-lessoer]

@elastic/kibana-app Any plans to solve that issue?