[ML] Machine Learning/Transforms: Use custom names for fields defined in index pattern field management

[walterra]

70039 introduces an option to define a custom label for Kibana index pattern fields.

Where applicable, the Machine Learning and Transforms plugin should make use of the feature.

Worth discussing on how to approach it:

• Anomaly Detection takes in a source index and writes anomalies to a different index. It is an ES backend task and doesn't know about Kibana index patterns. Should the UI try to consider custom labels from a source index and apply it to resulting anomaly fields on results pages?
• Data Frame Analytics take in a source index and write to a destination index. Using the UI, the user has the option to create a Kibana index pattern for the destination index. Should this step consider custom labels from the source index an apply it to the destination index?
• Transforms: When creating a transform using the wizard, the user has the option to define custom field names for the destination index. IMHO at this stage with this way of being able to customize, it would be overkill to add another option to define a Kibana related custom label. The main use case for those labels is when you cannot modify the original data and e.g. have long nested field names.
• For uses of data grid based previews of source data in ML/Transforms we should consider the custom label.

[elasticmachine]

Pinging @elastic/ml-ui (:ml)

[peteharverson]

My initial thoughts:

Anomaly Detection takes in a source index and writes anomalies to a different index. It is an ES backend task and doesn't know about Kibana index patterns. Should the UI try to consider custom labels from a source index an apply it to resulting anomaly fields on results pages?

My vote would be to use the displayName for the fields on the results pages. This would be in line with the approach we take for formatting actual and typical values for anomalies in the charts and table where we use the configured field format.

Data Frame Analytics take in a source index and write to a destination index. Using the UI, the user has the option to create a Kibana index pattern for the destination index. Should this step consider custom labels from the source index an apply it to the destination index?

My vote would be to duplicate the displayName for fields in the destination index pattern.

Transforms:` When creating a transform using the wizard, the user has the option to define custom field names for the destination index. IMHO at this stage with this way of being able to customize, it would be overkill to add another option to define a Kibana related custom

I agree there doesn't appear to be much value in adding another option to define displayName for fields in the KIbana index pattern, seeing as there is already a mechanism customizing the field name for the destination index.

[peteharverson]

Note when testing https://github.com/elastic/kibana/pull/101316 also found that if a custom label is set for a field, no row appears for that field in the data visualizer. See also https://github.com/elastic/kibana/issues/53480.