OpenSearch/docs/reference/setup/important-settings/node-name.asciidoc

[[node.name]]
=== `node.name`

Elasticsearch uses `node.name` as a human readable identifier for a
particular instance of Elasticsearch so it is included in the response
of many APIs. It defaults to the hostname that the machine has when
Elasticsearch starts but can be configured explicitly in
`elasticsearch.yml` as follows:

[source,yaml]
--------------------------------------------------
node.name: prod-data-2
--------------------------------------------------
Reorganize configuring Elasticsearch docs This commit reorganizes some of the content in the configuring Elasticsearch section of the docs. The changes are: - move JVM options out of system configuration into configuring Elasticsearch - move JVM options to its own page of the docs - move configuring the heap to important Elasticsearch settings - move configuring the heap to its own page of the docs - move all important settings to individual pages in the docs - remove bootstrap.memory_lock from important settings, this is covered in the swap section of system configuration Relates #27755 2017-12-12 10:24:37 -05:00			`[[node.name]]`
			=== `node.name`

Core: Default node.name to the hostname (#33677) Changes the default of the `node.name` setting to the hostname of the machine on which Elasticsearch is running. Previously it was the first 8 characters of the node id. This had the advantage of producing a unique name even when the node name isn't configured but the disadvantage of being unrecognizable and not being available until fairly late in the startup process. Of particular interest is that it isn't available until after logging is configured. This forces us to use a volatile read whenever we add the node name to the log. Using the hostname is available immediately on startup and is generally recognizable but has the disadvantage of not being unique when run on machines that don't set their hostname or when multiple elasticsearch processes are run on the same host. I believe that, taken together, it is better to default to the hostname. 1. Running multiple copies of Elasticsearch on the same node is a fairly advanced feature. We do it all the as part of the elasticsearch build for testing but we make sure to set the node name then. 2. That the node.name defaults to some flavor of "localhost" on an unconfigured box feels like it isn't going to come up too much in production. I expect most production deployments to at least set the hostname. As a bonus, production deployments need no longer set the node name in most cases. At least in my experience most folks set it to the hostname anyway. 2018-09-19 15:21:29 -04:00			Elasticsearch uses `node.name` as a human readable identifier for a
			`particular instance of Elasticsearch so it is included in the response`
			`of many APIs. It defaults to the hostname that the machine has when`
			`Elasticsearch starts but can be configured explicitly in`
			`elasticsearch.yml` as follows:
Reorganize configuring Elasticsearch docs This commit reorganizes some of the content in the configuring Elasticsearch section of the docs. The changes are: - move JVM options out of system configuration into configuring Elasticsearch - move JVM options to its own page of the docs - move configuring the heap to important Elasticsearch settings - move configuring the heap to its own page of the docs - move all important settings to individual pages in the docs - remove bootstrap.memory_lock from important settings, this is covered in the swap section of system configuration Relates #27755 2017-12-12 10:24:37 -05:00
			`[source,yaml]`
			`--------------------------------------------------`
			`node.name: prod-data-2`
			`--------------------------------------------------`