Searching logs by host name

[rsk0]

I have a little quandary. I'd like my customers to easily search for logs by host name. ECS has a field, host.name exactly for that information, but it's keyword, and that requires users know the exact capitalization and full name (which is sometimes hard to remember, like "DC1-ABcd99").

Is there a way I can continue to maintain ECS compatibility by keeping the field a keyword, but enable easier querying ("full text" I guess) for customers in Kibana?

[rsk0]

I can see there are many posts about how to do case insensitive searches.

My question is can I keep the field as keyword and enable easier searching in the UI, with lowercase and partial matching?

[ebeahan (Eric Beahan)]

One option is creating a multi-field of type text for the host.name field. Some ECS fields, like process.name, follow this convention and also define process.name.text.

host.name would remain a keyword field, and host.name.text would be the multi-field. Since host.name.text is indexed as type text, case insensitive search is supported.

Another option: some term-level query types, like wildcard, support a case_insensitive argument. Setting case_insensitive: true allows case-insensitive search against keyword fields for the supported query types.

[rsk0]

I like having a multi-field to make text searching easier, thanks for the idea.

Is there a way to have Kibana search host.name.text in addition to host.name when my customers search in Kibana for, say, host.name:dc1? I want to try to make it as easy as possible for them and not have to educate them about keyword fields (but I do want to try to stick to ECS).

Is the solution to have my customers always search host.name.text instead?

[rsk0]

I can see for some fields Kibana recognizes them as multi-fields, but when I add a host.name.text multi-field, its parent host.name doesn't show up as having a multi-field.

I don't see any real difference in the index mappings:

"process": {
  "properties": {
    "executable": {
      "type": "text",
      "fields": {
        "keyword": {
          "type": "keyword",
          "ignore_above": 256

v.

"host": {
  "properties": {
    "name": {
      "type": "keyword",
      "fields": {
        "text": {
          "type": "text"

[rsk0]

By the way, I missed this documentation earlier that says using text multi-fields is a blessed convention:

Conventions | Elastic Common Schema (ECS) Reference [8.4] | Elastic

[rsk0]

I'm still unable to get host.name to act as a multi-field.

I turned on Kibana's display of multi-fields so I can see, in another index/index pattern, that process.executable for example has a multi-field companion process.executable.keyword, and they're both marked as multi-fields:

But in this index/index pattern with field host.name, despite having created the same mapping arrangement as with process.executable / process.executable.keyword, the primary field does not show as a multi-field:

I'm left thinking that it's not just the mapping arrangement that needs to be correct, but something else too?

[ebeahan (Eric Beahan)]

After making the changes to your mappings, did you refresh your Kibana data views/index patterns? I'd give it a try to see if afterwards Kibana picks up the mapping change to what's expected.