# \`host.name\` and \`host.hostname\`
**URL:** https://discuss.elastic.co/t/host-name-and-host-hostname/339742
**Category:** Elasticsearch
**Tags:** ecs-elastic-common-schema
**Created:** [August 1, 2023, 4:59am UTC](https://discuss.elastic.co/t/host-name-and-host-hostname/339742 "2023-08-01T04:59:51Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@rsk0](https://discuss.elastic.co/u/rsk0)
#### Post date: [August 1, 2023, 4:59am UTC](https://discuss.elastic.co/t/host-name-and-host-hostname/339742/1 "2023-08-01T04:59:51Z")
What kind of values are folks using for `host.name` and `host.hostname`?
Basically I think ECS is encouraging FQDN in `host.name` and short name in `host.hostname`?
---
### Author:  [@Wolfram\_Haussig](https://discuss.elastic.co/u/Wolfram_Haussig)
#### Post date: [August 1, 2023, 11:10am UTC](https://discuss.elastic.co/t/host-name-and-host-hostname/339742/2 "2023-08-01T11:10:13Z")
Hi,
This might be an interesting discussion for you: [Clarify host.name vs. host.hostname · Issue #498 · elastic/ecs · GitHub](https://github.com/elastic/ecs/issues/498)
> Standard use case should be: all events have both `host.hostname` and `host.name` filled with the same information, the hostname of the machine.
> ...
> 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.
We are using this for servers with aliases:
- `host.hostname` contains the cryptic hostname, e.g. `debh103525`
- `host.name` contains the more readable server alias, e.g. `elastic-01.mycompany.com`
Best regards
Wolfram
---
### Author:  [@ebeahan](https://discuss.elastic.co/u/ebeahan)
#### Post date: [August 1, 2023, 7:32pm UTC](https://discuss.elastic.co/t/host-name-and-host-hostname/339742/3 "2023-08-01T19:32:27Z")
I agree with @Wolfram_Haussig.
Restating another way, `host.hostname` represents how the system ids itself (usually what's returned by the `hostname` command). And `host.name` more readable and meaningful, such as a fully-qualified hostname obtained through a reverse DNS lookup.
A less common but still valid use is described in [this GitHub comment](https://github.com/elastic/ecs/issues/498#issuecomment-509665674) from the issue already linked above. In a situation where many devices might have identical `hostname` values, `host.name` could contain a unique value.
For example, two laptops with a `host.hostname` of `erics-macbook` could have unique `host.name` values, like `Eric's Macbook` and `Eric's Backup Macbook`.
---
### Author:  [@rsk0](https://discuss.elastic.co/u/rsk0)
#### Post date: [August 3, 2023, 9:24pm UTC](https://discuss.elastic.co/t/host-name-and-host-hostname/339742/4 "2023-08-03T21:24:27Z")
This looks like it was a particularly thorny semantic to nail down. I don't envy the schema development work, it's complicated and interconnected and subtle. Even just trying to grasp it as a user and do the right thing is challenging.
So thanks a ton for the responses, @ebeahan and @Wolfram_Haussig
Another way I'm thinking of this is _along the lines_ of «[`host.name` is more of a "true identity", adapted to the user's environment"](https://github.com/elastic/ecs/issues/498#issuecomment-509665674)»: "really trying to provide the best unique/disambiguating identifier possible". A globally-unique identifier in the form of an FQDN is a good choice for that.
In our shop we have unique `hostname`s, thankfully, so we can use the more convenient-to-type-and-read _shorter_ names in a uniquely-identifying field.
Thanks again!
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [August 31, 2023, 9:24pm UTC](https://discuss.elastic.co/t/host-name-and-host-hostname/339742/5 "2023-08-31T21:24:48Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.