Add host.containerized and os.codename

[andrewvc]

This came up in #75 and elastic/beats#9154.

These fields seem useful. I notice no other fields in ECS are boolean, so this may be a first.

[webmat]

Thanks @andrewvc!

Not exactly the same semantics, but check out the definition for the new field os.full, wrt OS code names: https://github.com/elastic/ecs#os. Would this work for your use case?

As for host.containerized, a few things:

• I applaud you on your courage to introduce the first boolean! However you can only get that distinction if you actually make the field boolean, right now it's keyword ;-)
• Out of curiosity, in this case you're using host to report information from the point of view of the containerized process, correct? Can you expand on the situation, and perhaps give an example event how you would envision this?
  • I wonder if the .containerized field shouldn't be elsewhere, like perhaps process.containerized or service.containerized.

[MikePaquette]

@andrewvc @webmat at one point, we considered host.type: container as the way to capture this information. Would that work?

Other example values of host.type could be: { "hardware" , "virtual_machine" , "container" , "instance" , ... }

Now that we have the cloud.* fields, the current definition of host.type could be changed to reflect this if we think it would work.

[webmat]

Oh that could work too, indeed. You're right that the current host.type example (t2.medium) sounds redundant vs cloud.machine.type.

[andrewvc]

Is there still interest in this issue? CC @ppf2

[webmat]

We'll need to step back and have a broader discussion, for what happens here.

I could see some value in adding os.codename, although os already has a pretty good amount of fields. Not sure if adding codename in adition to name and full is all that useful.

As for host.containerized, we've discussed in other places that host was purely meant for a VM or a physical host. Not for a container. The container details belong in container. Do you know how host.containerized is being populated in Beats? I'd like to better understand the semantics.

The fix for what @ppf2 reported is actually a bugfix in Beats. If Beats populates these custom fields (at least custom for now), there should be a field definition added in libbeat/_meta/fields.common.yml.

[andrewvc]

@webmat I'm +1 for fixing this in beats as custom fields. I'm going to close this issue given that.

[ruflin]

@webmat We should sync up offline around if host is also mean for containers and others. Not sure if we are on the same page here.