@urso objections?

If text indexing is needed, it should be added as a multi-field at .meta.text

@ycombinator Ok? Don't see why this should be text.

Yep, makes sense as keyword to me.

Agreed

I screwed up. This should remain text IMHO. See my more-enlightened comment here: https://github.com/elastic/beats/pull/10318/files#r250673640

@webmat should we map this to url.original?

Yes, absolutely

Agreed

Yes, absolutely

If text indexing is needed, it should be added as a multi-field at .meta.text

I think this needs to be text. This value comes from the server.name setting in kibana.yml. The setting is meant for display purposes, according to it's documentation:

# The Kibana server's name.  This is used for display purposes.
#server.name: "your-hostname"

So it could be a string like "Marketing's Fantastic Analytics UI". In that case I can see the benefit of letting ES analyze the string. Thoughts?

If searching for specific words (e.g. "marketing", to follow your example), then we simply need server.name.text for these searches.

I agree it's really useful in situations where these resources are not always well tagged & so on.

But the canonical field -- server.name -- should really be keyword. Defaulting to keyword all the time, then only adding text as a multi-field when needed ensures this progression over time (adding text) is never a breaking change.

That sounds good to me but I have a tangential question:

IIRC if the server.name field is mapped as keyword in ES, it wouldn't also get a server.name.text multi-field automatically. Wouldn't we need to explicitly specify that somehow in the fields.yml so ES knows to create the multi-field? Or do all keyword fields in fields.yml automatically get a multi-field mapping added to them in the template via dynamic templates or something?

Another point: having server.name as keyword will enable users to aggregate per kibana server. It's the reason in ECS, we've decided to push for keyword across the board, by default

Haha I missed your answer when posting my previous message.

The template will have to create the multi-field explicitly for the .text.

Going for keyword across the board is also a small performance gain, so the default is kw only. Then we add text strategically, where it makes sense.

I'm not sure the exact incantation to make the multi-field in Beats fields.yml.

Gotcha, I understand now. Thanks. I'm good with changing this to keyword for now and adding a text multi-field later if we need.

@webmat Sounds like a field that should be mapped to ECS?

Yeah, agreed. url.original?

I noticed a few more things in this field defs:

• user => user.name
• script => file.path
• content_length => http.request.body.size
• request_method => http.request.method
• request_duration => event.duration, with an adjustment to nanos
• pid => process.pid

No longer sure if any of those were discussed in #10218

Looks like we should review php_fpm in detail again. Can you comment the above on #10218 so we can track it there?

👍