Configuring Elasticsearch
editConfiguring Elasticsearch
editElasticsearch ships with good defaults and requires very little configuration. Most settings can be changed on a running cluster using the Cluster update settings API.
The configuration files should contain settings which are node-specific (such
as node.name
and paths), or settings which a node requires in order to be
able to join a cluster, such as cluster.name
and network.host
.
Config files location
editElasticsearch has three configuration files:
-
elasticsearch.yml
for configuring Elasticsearch -
jvm.options
for configuring Elasticsearch JVM settings -
log4j2.properties
for configuring Elasticsearch logging
These files are located in the config directory, whose default location depends
on whether or not the installation is from an archive distribution (tar.gz
or
zip
) or a package distribution (Debian or RPM packages).
For the archive distributions, the config directory location defaults to
$ES_HOME/config
. The location of the config directory can be changed via the
ES_PATH_CONF
environment variable as follows:
ES_PATH_CONF=/path/to/my/config ./bin/elasticsearch
Alternatively, you can export
the ES_PATH_CONF
environment variable via the
command line or via your shell profile.
For the package distributions, the config directory location defaults to
/etc/elasticsearch
. The location of the config directory can also be changed
via the ES_PATH_CONF
environment variable, but note that setting this in your
shell is not sufficient. Instead, this variable is sourced from
/etc/default/elasticsearch
(for the Debian package) and
/etc/sysconfig/elasticsearch
(for the RPM package). You will need to edit the
ES_PATH_CONF=/etc/elasticsearch
entry in one of these files accordingly to
change the config directory location.
Config file format
editThe configuration format is YAML. Here is an example of changing the path of the data and logs directories:
path: data: /var/lib/elasticsearch logs: /var/log/elasticsearch
Settings can also be flattened as follows:
path.data: /var/lib/elasticsearch path.logs: /var/log/elasticsearch
In YAML, you can format non-scalar values as sequences:
discovery.seed_hosts: - 192.168.1.10:9300 - 192.168.1.11 - seeds.mydomain.com
Though less common, you can also format non-scalar values as arrays:
discovery.seed_hosts: ["192.168.1.10:9300", "192.168.1.11", "seeds.mydomain.com"]
Environment variable substitution
editEnvironment variables referenced with the ${...}
notation within the
configuration file will be replaced with the value of the environment
variable. For example:
node.name: ${HOSTNAME} network.host: ${ES_NETWORK_HOST}
Values for environment variables must be simple strings. Use a comma-separated string to provide values that Elasticsearch will parse as a list. For example, Elasticsearch will split the following string into a list of values for the ${HOSTNAME}
environment variable:
export HOSTNAME=“host1,host2"
Cluster and node setting types
editCluster and node settings can be categorized based on how they are configured:
- Dynamic
-
You can configure and update dynamic settings on a running cluster using the cluster update settings API. You can also configure dynamic settings locally on an unstarted or shut down node using
elasticsearch.yml
.Updates made using the cluster update settings API can be persistent, which apply across cluster restarts, or transient, which reset after a cluster restart. You can also reset transient or persistent settings by assigning them a
null
value using the API.If you configure the same setting using multiple methods, Elasticsearch applies the settings in following order of precedence:
- Transient setting
- Persistent setting
-
elasticsearch.yml
setting - Default setting value
For example, you can apply a transient setting to override a persistent setting or
elasticsearch.yml
setting. However, a change to anelasticsearch.yml
setting will not override a defined transient or persistent setting.It’s best to set dynamic, cluster-wide settings with the cluster update settings API and use
elasticsearch.yml
only for local configurations. Using the cluster update settings API ensures the setting is the same on all nodes. If you accidentally configure different settings inelasticsearch.yml
on different nodes, it can be difficult to notice discrepancies.