Clarify host.name vs. host.hostname

[roncohen]

Following up from #62, it's unclear when to use host.name and when to use host.hostname. APM sends host.hostname while beats send host.name. This is what ECS was designed to fix, so it looks like we need to clarify when to use what and potentially remove one of them.

[roncohen]

related: elastic/kibana#40486

[webmat]

The hostname of a machine should always be put in host.hostname. Beats is populating host.hostname, as far as I can tell. If you've seen a situation where that's not the case, please open an issue on the Beats repo.

host.name can contain the hostname by default, but it's meant to be a field people can override with a "better" identification for the host, if they have one (e.g. a cloud instance ID, an ID from their inventory management).

[webmat]

The descriptions for these fields kind of hint at this distinction, but it's probably not explicit enough. I'll make a note to clarify the relationship between these two fields.

[roncohen]

Ok. Could you elaborate on the use case? When is host.name applicable?

…

On Mon, 8 Jul 2019 at 20.53, Mathieu Martin ***@***.***> wrote: The descriptions for these fields kind of hint at this distinction, but it's probably not explicit enough. I'll make a note to clarify the relationship between these two fields. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#498?email_source=notifications&email_token=AAAAF2GA5GOHYGMDYWVZM33P6OEJJA5CNFSM4H62AF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZOARPA#issuecomment-509348028>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAF2D74Z24JGIF4BWNDL3P6OEJJANCNFSM4H62AF5A> .

[webmat]

Standard use case should be: all events have both host.hostname and host.name filled with the same information, the hostname of the machine.

If someone's environment creates duplicate hostnames or if users want to override with the ID or name from their inventory asset management system, they need to modify host.name accordingly, and leave host.hostname intact.

This way, host.hostname can always be trusted to reflect whatever the reality is on that server, whereas host.name is more of a "true identity", adapted to the user's environment.

Accordingly, Elastic SIEM is using host.name to distinguish hosts from one another. It was seen as the best combination of precision, configurability and user-friendliness (vs host.id).

[webmat]

@roncohen Did the explanation above make sense? Can we close this issue?

[roncohen]

OK, seems like we'd need to set both, allow users to override host.name and make all the UI use host.name?

[webmat]

Yes, precisely

…

On Wed, Jul 17, 2019 at 07:14 Ron Cohen ***@***.***> wrote: OK, seems like we'd need to set both and allow users to override host.name ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#498?email_source=notifications&email_token=AAAAR7AK5ZZEV4CIMGXQK3DP735KPA5CNFSM4H62AF5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2D3PCI#issuecomment-512210825>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAR7CBGTTYEURQMBJWVCTP735KPANCNFSM4H62AF5A> .

[roncohen]

thanks!

[roncohen]

there's still confusion about this. What can we do to clarify?

Ideas:

• rename host.name to something that makes things more clear? host.friendly_name, host.display_name
• retire host.name completely and ask people to use host.id if they want to give hosts a custom name?

[webmat]

Could you open a new issue detailing what the confusion is?

[johncollaros]

Comparing beats output in 7.6.2 release:
metricbeat, filebeat: host.name = host.hostname, which is the plain hostname of the machine.
winlogbeat: host.name != host.hostname; host.name = FQDN, host.hostname = plain hostname

This causes Kibana apps such as metric explorer to show two instances of the host.

It's not clear which field should be used, and the beats do not seem to use host.name field consistently.

[webmat]

@johncollaros ECS defines the schema, but doesn't take part in implementing it across all of our products. Please raise this issue with Beats.