Elasticsearch uses a YAML (Yet Another Markup Language) configuration file that can be found inside the default Elasticsearch directory (RPM and DEB installs change this location amongst other things).

You can set basic settings in config/elasticsearch.yml:

# Change the cluster name. All nodes in the same cluster must use the same name!
cluster.name: my_cluster_name

# Set the node's name using the hostname, which is an environment variable!
# This is a convenient way to uniquely set it per machine without having to make
#  a unique configuration file per node.
node.name: ${HOSTNAME}

# ALL nodes should set this setting, regardless of node type
path.data: /path/to/store/data

# This is a both a master and data node (defaults)
node.master: true
node.data: true

# This tells Elasticsearch to bind all sockets to only be available
#  at localhost (default)
network.host: _local_

If you need to apply a setting dynamically after the cluster has already started, and it can actually be set dynamically, then you can set it using _cluster/settings API.

Persistent settings are one of the two type of cluster-wide settings that can be applied. A persistent setting will survive a full cluster restart.

Note: Not all settings can be applied dynamically. For example, the cluster's name cannot be renamed dynamically. Most node-level settings cannot be set dynamically either (because they cannot be targeted individually).

This is not the API to use to set index-level settings. You can tell that setting is an index level setting because it should start with index.. Settings whose name are in the form of indices. are cluster-wide settings because they apply to all indices.

POST /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "none"
  }
}

Warning: In Elasticsearch 1.x and 2.x, you cannot unset a persistent setting.

Fortunately, this has been improved in Elasticsearch 5.x and you can now remove a setting by setting it to null:

POST /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

An unset setting will return to its default, or any value defined at a lower priority level (e.g., command line settings).

If you need to apply a setting dynamically after the cluster has already started, and it can actually be set dynamically, then you can set it using _cluster/settings API.

Transient settings are one of the two type of cluster-wide settings that can be applied. A transient setting will not survive a full cluster restart.

Note: Not all settings can be applied dynamically. For example, the cluster's name cannot be renamed dynamically. Most node-level settings cannot be set dynamically either (because they cannot be targeted individually).

This is not the API to use to set index-level settings. You can tell that setting is an index level setting because it should start with index.. Settings whose name are in the form of indices. are cluster-wide settings because they apply to all indices.

POST /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}

Warning: In Elasticsearch 1.x and 2.x, you cannot unset a transient settings without a full cluster restart.

Fortunately, this has been improved in Elasticsearch 5.x and you can now remove a setting by setting it to null:

POST /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": null
  }
}

An unset setting will return to its default, or any value defined at a lower priority level (e.g., persistent settings).

Index settings are those settings that apply to a single index. Such settings will start with index.. The exception to that rule is number_of_shards and number_of_replicas, which also exist in the form of index.number_of_shards and index.number_of_replicas.

As the name suggests, index-level settings apply to a single index. Some settings must be applied at creation time because they cannot be changed dynamically, such as the index.number_of_shards setting, which controls the number of primary shards for the index.

PUT /my_index
{
  "settings": {
    "index.number_of_shards": 1,
    "index.number_of_replicas": 1
  }
}

or, in a more concise format, you can combine key prefixes at each .:

PUT /my_index
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

The above examples will create an index with the supplied settings. You can dynamically change settings per-index by using the index _settings endpoint. For example, here we dynamically change the slowlog settings for only the warn level:

PUT /my_index/_settings
{
  "index": {
    "indexing.slowlog.threshold.index.warn": "1s",
    "search.slowlog.threshold": {
      "fetch.warn": "500ms",
      "query.warn": "2s"
    }
  }
}

Warning: Elasticsearch 1.x and 2.x did not very strictly validate index-level setting names. If you had a typo, or simply made up a setting, then it would blindly accept it, but otherwise ignore it. Elasticsearch 5.x strictly validates setting names and it will reject any attempt to apply index settings with an unknown setting(s) (due to typo or missing plugin). Both statements apply to dynamically changing index settings and at creation time.

You can apply the same change shown in the Index Settings example to all existing indices with one request, or even a subset of them:

PUT /*/_settings
{
  "index": {
    "indexing.slowlog.threshold.index.warn": "1s",
    "search.slowlog.threshold": {
      "fetch.warn": "500ms",
      "query.warn": "2s"
    }
  }
}

or

PUT /_all/_settings
{
  "index": {
    "indexing.slowlog.threshold.index.warn": "1s",
    "search.slowlog.threshold": {
      "fetch.warn": "500ms",
      "query.warn": "2s"
    }
  }
}

or

PUT /_settings
{
  "index": {
    "indexing.slowlog.threshold.index.warn": "1s",
    "search.slowlog.threshold": {
      "fetch.warn": "500ms",
      "query.warn": "2s"
    }
  }
}

If you prefer to more selectively do it as well, then you can select multiple without supply all:

PUT /logstash-*,my_other_index,some-other-*/_settings
{
  "index": {
    "indexing.slowlog.threshold.index.warn": "1s",
    "search.slowlog.threshold": {
      "fetch.warn": "500ms",
      "query.warn": "2s"
    }
  }
}