Spaces in field names?

Elastic Stack Kibana
1

What is the status of support for spaces in field names; specifically, from Kibana 7.11.2 onwards?

I've read conflicting information about this.

For example, here's a reply from an Elastic Team Member to the forum topic "Fields didn't show up":

I believe you may be seeing this issue due to the spaces in the field names. This isn't something that Elasticsearch supports. Can you try again with a log file where the spaces are converted to underscores instead? For example, instead of "new socket" the field name should be "new_socket".

But then, the Kibana GitHub pull request "[Mappings editor] Allow spaces in field names" (#54529) has been marked as closed.

And, while the workaround described in the discussion forum topic "How to query in kibana for a column name having space in it" is onerous (escaping spaces with a backslash) , the implicit message is that spaces are allowed.

I'd appreciate a definitive answer from the Elastic Team about the support for spaces in field names in (a) Kibana and (b) Elasticsearch. (It occurs to me that, if Elasticsearch supports spaces in field names, it doesn't necessarily follow that Kibana also supports spaces in field names.)

In each case: what are the practical issues involved? (For example, in Kibana, having to use a backslash on the Discover tab. And: do some panel/visualization editors in Kibana support spaces in fields, while others do not?)

2

I've read Elastic Common Schema (ECS) Reference > Using ECS > Guidelines and Best Practices:

Guidelines for field names

  • Field names must be lower case
  • Combine words using underscore

Still, my questions about support—as opposed to guidelines and best practices in the context of ECS—remain.

3

In the past, I've successfully used fields with spaces in their names in Kibana visualizations.

But perhaps I was just "lucky"; perhaps I unknowingly stepped around issues with such fields.

4

In 7.12 it's possible to define a display name per field on the index pattern in Kibana. To my knowledge there shouldn't be any issues with using spaces in those display names, while keeping the underlying mapping close to the standard.

5

Yes, I've been following the progress of display names (custom labels) per field defined in index patterns.

From the Kibana docs topic "Field management":

Queries and filters don't currently support a custom label and will use the original field name.

(Are custom labels supported by all panel/visualization editors? I'm guessing using Vega also means using the original field names, right?)

I'm helping to develop an application that forwards proprietary events and metrics data in JSON Lines format. The application could potentially offer the following choices of keys (field names):

  • Compact, cryptic names. All lowercase, no spaces, no special characters, not even underscores. Just a-z, 0-9. First character must be a letter (go ahead, ask :wink: ). e.g. indecpup
  • Longer, more human-readable names in snake case. As above, but longer, and with underscores. e.g. independent_enclave_cpu_percent
  • Display-friendly names. Mixed case, with spaces and special characters. e.g. Independent enclave CPU %

While I like the idea of the combination of:

  • Compact field names in the underlying data to conserve storage, mapped (via, in the case of Elastic, a Kibana index pattern) to
  • Longer, human-readable, display-friendly custom labels in a UI

the fact that there are still contexts in which users need to work directly with the underlying field names make the snake-case names more palatable.

6

Yeah, there are places in Kibana which don't use the display names (like vega).

I think snake case for the real fields in Elasticsearch plus display friendly names on the index pattern are a good compromise. In most cases regular users won't hit the places where display names are not shown.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.