Elasticsearch => Elasticsearch-konfiguration

Anmärkningar

Elasticsearch levereras med en uppsättning standardvärden som ger en god upplevelse för utveckling. Det implicita uttalandet där är att det inte nödvändigtvis är bra för produktion, som måste skräddarsys för dina egna behov och därför inte kan förutsägas.

Standardinställningarna gör det enkelt att ladda ner och köra flera noder på samma maskin utan några konfigurationsändringar.

Var är inställningarna?

Inuti varje installation av Elasticsearch finns en config/elasticsearch.yml . Det är där följande inställningar bor:

cluster.name
- Namnet på det kluster som noden går med i. Alla noder i samma kluster måste ha samma namn.
- För närvarande är standard för elasticsearch .
node.*
- node.name
  - Om inte levereras kommer ett slumpmässigt namn att genereras varje gång noden startar . Detta kan vara roligt, men det är inte bra för produktionsmiljöer.
  - Namnen behöver inte vara unika, men de bör vara unika.
- node.master
  - En boolesk inställning. När det är true betyder det att noden är en valbar huvudnod och att den kan vara den valda huvudnoden.
  - Som standard är true , vilket betyder att varje nod är en kvalificerad huvudnod.
- node.data
  - En boolesk inställning. När det är true betyder det att noden lagrar data och hanterar sökaktivitet.
  - Standardvärdet är true .
path.*
- path.data
  - Platsen som filer skrivs för noden. Alla noder använder den här katalogen för att lagra metadata, men datanoderna kommer också att använda den för att lagra / indexera dokument.
  - Standardvärdet för ./data .
    - Detta innebär att data skapas för dig som en peer-katalog för att config inuti Elasticsearch-katalogen.
- path.logs
  - Platsen som loggfiler skrivs.
  - Standardvärdet för ./logs .
network.*
- network.host
  - Standardvärdet till _local_ , som är effektivt localhost .
    - Detta innebär att noder som standard inte kan kommuniceras med utanför den aktuella maskinen!
- network.bind_host
  - Potentiellt en matris, detta berättar för Elasticsearch vilka adresser för den aktuella maskinen också binder uttag.
    - Det är denna lista som gör att maskiner utanför maskinen (t.ex. andra noder i klustret) kan prata med den här noden.
  - Standardinställningar för network.host .
- network.publish_host
  - En enkel värd som används för att annonsera till andra noder hur man bäst kan kommunicera med denna nod.
    - När de tillhandahåller en array till network.bind_host , bör detta vara en värd som är avsedd att användas för inter-nod kommunikation.
  - Standardinställningar för nätverk.host`.
discovery.zen.*
- discovery.zen.minimum_master_nodes
  - Definierar kvorum för mästerval. Detta måste ställas in med hjälp av denna ekvation: (M / 2) + 1 där M är antalet kvalificerade huvudnoder (noder som använder node.master: true implicit eller uttryckligen).
  - Standardvärdet är 1 , vilket endast är giltigt för ett enda nodkluster!
- discovery.zen.ping.unicast.hosts
  - Mekanismen för att ansluta denna nod till resten av ett kluster.
  - Detta bör lista berättigade huvudnoder så att en nod kan hitta resten av klustret.
  - Värdet som ska användas här är network.publish_host för de andra noderna.
  - Standardvärdet för localhost , vilket innebär att den bara ser på den lokala maskinen för att ett kluster ska gå med.

Vilken typ av inställningar finns?

Elasticsearch erbjuder tre olika typer av inställningar:

Cluster-breda inställningar
- Det här är inställningar som gäller för allt i klustret, till exempel alla noder eller alla index.
Nodinställningar
- Det här är inställningar som gäller bara den aktuella noden.
Indexinställningar
- Det här är inställningar som gäller bara indexet.

Beroende på inställning kan det vara:

Förändrades dynamiskt vid körning
Ändrades efter en omstart (stäng / öppen) av indexet
- Vissa inställningar på indexnivå kräver inte att indexet ska stängas och öppnas igen, men kan kräva att indexet tvångsförenas igen för att inställningen ska tillämpas.
  - Kompressionsnivån för ett index är ett exempel på denna typ av inställning. Det kan ändras dynamiskt, men bara nya segment utnyttjar förändringen. Så om ett index inte kommer att ändras, utnyttjar det aldrig ändringen om du inte tvingar indexet att återskapa sina segment.
Ändrade efter en omstart av noden
Ändrade efter en omstart av klustret
Har aldrig förändrats

Kontrollera alltid dokumentationen för din version av Elasticsearch för vad du kan eller inte kan göra med en inställning.

Hur kan jag tillämpa inställningar?

Du kan ställa inställningar på några sätt, av vilka några inte föreslås:

Kommandoradsargument

I Elasticsearch 1.x och 2.x kan du skicka in de flesta inställningar som Java-systemegenskaper förinställda med es. :

$ bin/elasticsearch -Des.cluster.name=my_cluster -Des.node.name=`hostname`

I Elasticsearch 5.x ändras detta för att undvika att använda Java-systemegenskaper, istället använder du en anpassad argumenttyp med -E i stället för -Des. :

$ bin/elasticsearch -Ecluster.name=my_cluster -Enode.name=`hostname`

Denna strategi för att tillämpa inställningar fungerar bra när du använder verktyg som Puppet, Chef eller Ansible för att starta och stoppa klustret. Men det fungerar mycket dåligt när man gör det manuellt.

YAML-inställningar
- Visas i exempel
Dynamiska inställningar
- Visas i exempel

Den ordning som inställningarna tillämpas är i den mest dynamiska ordningen:

Övergående inställningar
Persistenta inställningar
Kommandoradsinställningar
YAML (statiska) inställningar

Om inställningen ställs in två gånger, en gång på någon av dessa nivåer, träder den högsta nivån i kraft.

Static Elasticsearch Settings

Elasticsearch använder en YAML (Yet Another Markup Language) konfigurationsfil som finns i standardkatalogen Elasticsearch ( RPM och DEB installerar ändrar bland annat denna plats ).

Du kan ställa in grundinställningar i 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_

Persistenta dynamiska klusterinställningar

Om du behöver tillämpa en inställning dynamiskt efter att klustret redan har startat, och det faktiskt kan ställas in dynamiskt, kan du ställa in det med _cluster/settings API.

Persistenta inställningar är en av de två typen av klusterövergripande inställningar som kan tillämpas. En ihållande inställning kommer att överleva en fullständig omstart av kluster.

Obs! Inte alla inställningar kan tillämpas dynamiskt. Till exempel kan inte klusterens namn bytas om dynamiskt. De flesta nodnivåinställningar kan inte heller ställas in dynamiskt (eftersom de inte kan riktas individuellt).

Detta är inte det API som ska användas för att ställa in indexnivåinställningar. Du kan säga att inställningen är en indexnivåinställning eftersom den bör börja med index. . Inställningar vars namn är i form av indices. är klusteromfattande inställningar eftersom de gäller alla index.

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

Varning : I Elasticsearch 1.x och 2.x kan du inte återställa en bestående inställning.

Lyckligtvis har detta förbättrats i Elasticsearch 5.x och du kan nu ta bort en inställning genom att ställa in den till null :

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

En inställd inställning kommer att återgå till dess standardvärde eller valfritt värde definierat till en lägre prioritetsnivå (t.ex. kommandoradsinställningar).

Transient Dynamic Cluster Settings

Om du behöver tillämpa en inställning dynamiskt efter att klustret redan har startat, och det faktiskt kan ställas in dynamiskt, kan du ställa in det med _cluster/settings API.

Övergående inställningar är en av de två typen av klusterövergripande inställningar som kan tillämpas. En övergående inställning kommer inte att överleva en fullständig kluster omstart.

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

Varning : I Elasticsearch 1.x och 2.x kan du inte återställa övergående inställningar utan en fullständig omstart av kluster.

Lyckligtvis har detta förbättrats i Elasticsearch 5.x och du kan nu ta bort en inställning genom att ställa in den till null:

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

En inställd inställning kommer att återgå till dess standardvärde eller valfritt värde definierat till en lägre prioritetsnivå (t.ex. persistent inställningar).

Indexinställningar

Indexinställningar är de inställningar som gäller för ett enda index. Sådana inställningar börjar med index. . Undantaget från denna regel är number_of_shards och number_of_replicas , som också finns i form av index.number_of_shards och index.number_of_replicas .

Som namnet antyder gäller indexnivåinställningar för ett enda index. Vissa inställningar måste tillämpas vid skapelsetid eftersom de inte kan ändras dynamiskt, till exempel inställningen index.number_of_shards , som styr antalet primära skär för indexet.

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

eller i ett mer kortfattat format kan du kombinera nyckelforfix vid varje . :

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

Ovanstående exempel skapar ett index med de medföljande inställningarna. Du kan dynamiskt ändra inställningar per index genom att använda slutpunkten för index _settings . Här ändrar vi till exempel dynamiska inställningar för slowlog för endast varningsnivån:

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

Varning : Elasticsearch 1.x och 2.x validerade inte riktigt inställningsnamnen på indexnivå. Om du hade en skrivfel, eller helt enkelt gjort en inställning, skulle den blint acceptera den, men annars ignorera den. Elasticsearch 5.x validerar strikt inställningsnamn och det avvisar alla försök att tillämpa indexinställningar med okända inställningar (på grund av typfel eller saknas plugin). Båda uttalandena gäller dynamiskt ändrade indexinställningar och vid skapandet.

Dynamiska indexinställningar för flera index samtidigt

Du kan tillämpa samma ändring som visas i Exempel på Index Settings på alla befintliga index med en begäran eller till och med en delmängd av dem:

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

eller

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

eller

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

Om du föredrar att mer selektivt gör det också, kan du välja flera utan att leverera alla:

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

Modified text is an extract of the original Stack Overflow Documentation

Licensierat under CC BY-SA 3.0

Inte anslutet till Stack Overflow

Elasticsearch
Elasticsearch-konfiguration

Sök…