Elasticsearch

Logs / Ereignisse lassen sich auf verschiedene Weise anzeigen.
Man kann sie sich einfach auf der Konsole ausgeben lassen, oder man speichert sie in
Log-Dateien ab, oder man legt sie in eine Datenbank ab.

Wenn man viele Logs / Ereignisse speichern muss und diese dann schnell abrufen möchte, bietet sich hier eine Datenbank an.
Jedoch nicht jede Datenbank eignet sich für diese Zwecke, da evtl. einfach zu viele Einträge, Tabellen o.ä. aufkommen werden.

Elasticsearch ist eine Datenbank die mit diesen Anforderungen klar kommt.

Hier ein Vergleich zu einer mySQL Datenbank.

• MySQL ⇒ Datenbanken ⇒ Tabellen ⇒ Spalten/Reihen
• Elasticsearch ⇒ Indexe ⇒ Typen ⇒ Documente mit Eigenschaften

Vorbereitend installiert man noch Die JAVA-JDK Pakete.

apt-get install default-jre

Danach kann Elasticsearch wie folgt installiert werden.

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-<VERSION>.deb

dpkg -i elasticsearch-<VERSION>.deb

Damit der Elasticsearch Daemon beim Booten automatisch von „systemd“ gestartet wird, führt man noch folgende Befehle aus.

systemctl daemon-reload
systemctl enable elasticsearch.service

Starten kann man Elasticsearch mit:

systemctl start elasticsearch.service

Vor dem ersten Start müssen noch folgende Einstellungen in der elasticsearch.yml vorgenommen werden:

• path.data and path.logs
  • /etc/default/elasticsearch: DATA_DIR= und LOG_DIR=
• cluster.name
  • /etc/elasticsearch/elasticsearch.yml: cluster.name:
• node.name
  • /etc/elasticsearch/elasticsearch.yml: node.name:
• Swap
  • wenn es geht sollte auf dem Server nur Elasticsearch laufen, somit kann man dann auch Swapping ausschalten: in der fstab die Zeilen mit swap auskommentieren
  • eine andere Möglichkeit ist bootstrap.memory_lock in der elasticsearch.yml einzuschalten: bootstrap.memory_lock: true
• Netzwerk
  • siehe netzwerkeinstellungen
• Cluster Konfigurieren
  • um einen Cluster zu definieren, einfach folgendes in der /etc/elasticsearch/elasticsearch.yml eintragen: discovery.zen.ping.unicast.hosts: [„HOST1“, „HOST2“, …]
  • weiterhin muss, wenn es sich um einen Masternode handelt, die min. Anzahl an Nodes definiert werden, falls es einen Split-Brain gibt: discovery.zen.minimum_master_nodes: 1
• JVM Heapsize
  • in der /etc/elasticsearch/jvm.options kann man die Heapsize mit den Parametern -Xms (minimum) und Xmx (maximum) setzen
  • Beide Parameter sollten in gleicher höhe gesetzt werden und nicht mehr als 50% des RAM überschreiten
• Limit geöffnete Dateien (siehe auch to_many_files_open)
  • Elasticsearch bedient viele gleichzeitig geöffnete Dateien, daher muss dem User unter dem Elasticsearch läuft erlaubt werden viele Dateien gleichzeitig geöffnet zu haben
  • /etc/security/limits.conf: folgendes unten einfügen

    elasticsearch   -       nofile          65536
    elasticsearch   soft    nproc           2048
    elasticsearch   hard    nproc           2048

• Virtueller Speicher
  • Elasticsearch nutzt in 64bit Umgebungen „mmapfs“ Ordner zum Speichern seinder Indices. Standardmäßig limitiert das Betriebssystem die Speichermenge von „mmap“. Die muss erhöht werden.
  • /etc/sysctl.conf: hier folgendes unten einfügen vm.max_map_count = 262144
• Anzahl an Threads
  • Elasticsearch erstellt sich automatisch neue Threads wenn es diese benötigt. Damit dies auch beliebig viel passieren kann, muss dem Benutzer unter dem Elasticsearch läuft, die Anzahl erhöht werden.
  • /etc/security/limits.conf: elasticsearch soft nproc 2048 und elasticsearch hard nproc 2048 unten einfügen

Nachdem nun alles konfiguriert und gesetzt ist, startet man den Server neu um alles zu aktivieren. Danach kann Elasticsearch produktiv genutzt werden.

Standardmäßig legt Elasticsearch seine Datenbank unter folgendem Pfad ab: /var/lib/elasticsearch/<CLUSTERNAME>/node/<NODENUMMER>
Wenn nun der Pfad umgelegt werden muß (Platzgründe, Sicherheitsaspekte,…), dann muß dies hier angegeben werden.

vi /etc/elasticsearch/elasticsearch.yml

Hier sollte man folgende Variablen pflegen:

# Elasticsearch log directory
path.logs: <PFAD>
 
# Elasticsearch data directory
path.data: <PFAD>

Die Daten- und Logverzeichnisse müssen für den Benutzer, unter dem Elasticsearch läuft, beschreibbar sein.
Man kann entsprechende Schreibrechte vergeben, oder den Elasticsearch Benutzer als Besitzer angeben:

chown -R elasticsearch.elasticsearch <PFAD_ZU_ELASTICSEARCH_DATA_DIR>

chown -R elasticsearch.elasticsearch <PFAD_ZU_ELASTICSEARCH_LOG_DIR>

Nach der Installation kann nun die Datenbank wie folgt gestartet werden:

systemctl start elasticsearch

Nun sollten mit folgendem Befehl die Ports „9200“ und „9300“ in Gebrauch sein:

netstat -tulpen|grep -i LISTEN

Mit dem folgenden Befehl prüft man nun auf dem Server selbst, ob der Elasticsearch-Server anfragen annimmt und auch antwortet.

curl -XGET -k -u <USERNAME> https://localhost:9200

Die Anwort sollte ungefähr dies ausgeben.

{
  "name" : "<NODE_NAME>",
  "cluster_name" : "<CLUSTER_NAME>",
  "version" : {
    "number" : "<VERSION_NUMBER>",
    "build_hash" : "<HASH>",
    "build_timestamp" : "<TIMESTAMP>",
    "build_snapshot" : false,
    "lucene_version" : "<VERSION_NUMBER>"
  },
  "tagline" : "You Know, for Search"
}

Hier noch Befehle zum Status des Clusters und des gestarteten Nodes:
Global Health

curl -k -u <USERNAME> https://localhost:9200/_cat/health?v

Clusterinfo

curl -k -u <USERNAME> https://localhost:9200/_cat/cluster?v

Nodeinfo

curl -k -u <USERNAME> https://localhost:9200/_cat/nodes?v

• log4j2.properties: Um das Log-Level von Elasticsearch hoch zu setzen, einfach in der log4j2.properties den Wert von status von error auf debug setzen und elasticsearch neustarten.
• systemd: Weiterhin kann man in der /usr/lib/systemd/system/elasticsearch.service die Startoptionen für elasticsearch anpassen. Einfach von –quiet auf –verbose ändern.

Die Log-Datei findet man dann unter /<PFAD_ZU_LOGS>/<CLUSTERNAME>.log oder man schaut in die /var/log/syslog rein.

• live: Im laufenden Betrieb kann der Log-Level mittels _cluster/settings gesetzt werden

  curl -XPUT -k -u <USERNAME> "https://localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
  {
    "transient": {
      "logger._root" : "DEBUG"
    }
  }
  '

  Zum Abschalten einfach „logger._root“ : null per curl absetzen

Neues Dokument per Console erstellen

curl -XPUT -k -u <USERNAME> "https://localhost:9200/[INDEXNAME]/_doc/1?pretty" -H 'Content-Type: application/json' -d'
{
    "user" : "stizi",
    "post_date" : "2019-08-27T11:29:12",
    "message" : "Hallo Elasticsearch"
}
'

Standardmäßig ist der Elasticsearch-Server nur vom Localhost erreichbar (Networkbind auf Localhost).
Damit dieser vom Netzwerk erreichbar wird, müssen folgende Parameter in die elasticsearch.yml.

network.host: <IP_DES_ELASTICSEARCH_SERVERS>

Oder so:

network.bind_host: <IP_ADRESSE_DES_ELASTICSEARCH_NODES>
network.publish_host: <IP_ADRESSE_DES_ELASTICSEARCH_NODES>

Folgende Angaben können zu den Parametern network.bind_host und network.publish_host verwendet werden (Quelle: www.elastic.co):

Diese Einstellungen sollten in den jew. Modulen, z.B. im HTTP-Modul (siehe Module) auch angepasst werden.

Wenn man Elasticsearch auf mehreren Servern, im gleichen Netzwerk, installiert, beide nicht wesentlich konfiguriert, dann finden sich beide und fangen an sich zu synchronisieren.
Das geschieht deshalb, weil beide den selben Clusternamen haben und das „Zen-Discovery“ standardmäßig eingeschaltet ist.

• „transient“ Cluster-Einstellungen haben Vorrang vor „persistent“ Cluster-Einstellungen, sie haben auch Vorrang vor Einstellungen, welche in der Konfigurationsdatei elasticsearch.yml konfiguriert sind.

Mit curl können auf der Command-Line Einstellungen gesetzt werden.

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
    "persistent" : { },
    "transient" : {
        "indices.recovery.max_bytes_per_sec" : "20mb"
    }
}
'

noch ein Beispiel

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
  "persistent" : {
    "cluster.max_shards_per_node" : 4000
},
  "transient" : { }
}
'

oder das Ganze in einer Zeile

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d' {"transient":{"indices.recovery.max_bytes_per_sec":20mb}}'

Um Einstellungen zu ändern einfach diese überschreiben.
Wenn Einstellunge geöscht werden sollen, müssen sie genullt werden.

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d' {"transient":{"indices.recovery.max_bytes_per_sec":null}}'

Möchte man nur einen Node betreiben, dann sollten folgende Parameter in der elasticsearch.yml gesetzt sein, um einen grünen Clusterstate zu erhalten:

gateway.expected_master_nodes: 1
gateway.expected_data_nodes: 1
gateway.recover_after_time: 5m
gateway.recover_after_nodes: 1
gateway.recover_after_master_nodes: 1
gateway.recover_after_data_nodes: 1

Zusätzlich sollten noch diese dynamischen Einstellungen vorgenommen werden:

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_settings?pretty' -H 'Content-Type: application/json' -d'
{
    "index.number_of_replicas" : 0
}
'

Da diese keine Einstellungen für Cluster sind, wird hier nur …/_settings… verwendet. Darüber hinaus gibt es keine persistent oder transient Einstellungen ausserhalb der Clustereinstellungen.

Diese Einstellungen sind lange nicht alles was dazu einzurichten ist. Dies soll nur einen kleinen Einblick in die Konfiguration bieten.
Weitere Infos findet man unter Modules-Cluster

Die hier genannten Einstellungen sind nur Vorschläge/Standardwerte und sollten nach eigenem Ermessen angepasst werden.
Ich gehe hier von 2 Elasticsearch Nodes der Version 5.6 aus.
Beide Nodes sind Master und Data Nodes.

Somit ergibt sich folgender Curl Befehl.
Node1 und Node2

curl -u elastic -XPUT 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
    "persistent" : {
        "cluster.routing.allocation.enable" : "all",
        "cluster.routing.allocation.node_concurrent_recoveries" : "2",
        "cluster.routing.allocation.node_initial_primaries_recoveries" : "4",
        "cluster.routing.allocation.same_shard.host" : "false",
        "cluster.routing.rebalance.enable" : "all",
        "cluster.routing.allocation.allow_rebalance" : "indices_all_active",
        "cluster.routing.allocation.cluster_concurrent_rebalance" : "2",
        "cluster.routing.allocation.balance.shard" : "0.45f",
        "cluster.routing.allocation.balance.index" : "0.55f",
        "cluster.routing.allocation.balance.threshold" : "1.0f",
        "cluster.routing.allocation.disk.threshold_enabled" : "true",
        "cluster.routing.allocation.disk.watermark.low" : "10gb",
        "cluster.routing.allocation.disk.watermark.high" : "5gb",
        "cluster.info.update.interval" : "1m",
        "cluster.routing.allocation.disk.include_relocations" : "true",
        "cluster.blocks.read_only" : "false",
        "cluster.blocks.read_only_allow_delete" : "false"
    }
}
'

Diese Einstellungen müssen bei beiden Nodes in der elasticsearch.yml vorgenommen und jew. angepasst werden werden.

"node.master" : "true",
"node.data" : "true",
"cluster.name" : "cluster-stizi",
"node.name" : "node<NUMMER>-${HOSTNAME}",
"discovery.zen.join_timeout" : "3s",
"discovery.zen.ping.unicast.hosts" : "<IP_ADRESSEN_ANDERER_NODES>",
"discovery.zen.ping.unicast.hosts.resolve_timeout" : "5s",
"discovery.zen.minimum_master_nodes" : "2",
"discovery.zen.no_master_block" : "all",
"gateway.expected_nodes" : "2",
"gateway.expected_master_nodes" : "2",
"gateway.expected_data_nodes" : "2",
"gateway.recover_after_time" : "5m",
"gateway.recover_after_nodes" : "2",
"gateway.recover_after_master_nodes" : "2",
"gateway.recover_after_data_nodes" : "2",
"network.host" : [<IP1>, <IP2>, <HOSTNAME>,...]

Wartungsmodus ein
Möchte man einen Node zu Wartungszwecken abschalten/neustarten, dann sollten Shards in dieser Zeit nicht hin und her repliziert werden.
Dazu schaltet man die Shard-Allocation ab, indem man es auf nur primäre Shards begrenzt (siehe auch Balancing.

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'{"persistent":{"cluster.routing.allocation.enable": primaries}}'

Um die Wiederherstellung der Shards zu beschleunigen, kann es sinnvoll sein den Index zu leeren.

curl -XPOST -k -u <USERNAME> 'https://localhost:9200/_flush?pretty'

Machine Learning Jobs hält man wie folgt an.

curl -XPOST -k -u <USERNAME> 'https://localhost:9200/_ml/set_upgrade_mode?enabled=true&pretty'

Wartungsmodus aus
Wenn alle Nodes wieder gestartet und erreichbar sind, prüft man mit folgendem Befehl ob alle im Cluster verfügbar sind

curl -XGET -k -u <USERNAME> 'https://localhost:9200/_cat/nodes?pretty'

Danach schaut man in welchem Status sich der Cluster befindet.

curl -XGET -k -u <USERNAME> "localhost:9200/_cat/health?pretty"

Nach einem frischen Start eines Nodes, wird dieser sich zum Cluster verbinden und zunächst seine eigenen Shards wiederherstellen. Der Cluster befindet sich dann im Status rot.
Danach erhält der Cluster den Status gelb, da alle lokalen Shards verfügbar sind, aber nicht alle Shards an allen Nodes repliziert sind.

Erst jetzt kann man das Replizieren der Shards wieder einschalten.

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'{"persistent":{"cluster.routing.allocation.enable": null}}'

Wenn das Replizieren der Shards läuft, kann man in Elasticsearch wieder suchen, Indizes erstellen und Machine Learning Jobs starten.
Damit der Cluster nicht bei der Replizierung auch noch mit allen anderen Aufgaben zu tun hat, macht es Sinn abzuwarten, bis der Cluster Status wieder grün ist.

Zuletzt schaltet man Machine Learning Jobs wieder ein.

curl -XPOST -k -u <USERNAME> 'https://localhost:9200/_ml/set_upgrade_mode?enabled=false&pretty'

Mit folgendem Befehl kann man sehen welche Plugins für Elasticsearch installiert sind.

curl -k -u <USERNAME> 'https://localhost:9200/_cat/plugins?v'

oder

/usr/share/elasticsearch/bin/elasticsearch-plugin list

Man findet Plugins bei GitHub.
Installiert werden sie mit folgendem Befehl:

/usr/share/elasticsearch/bin/elasticsearch-plugin install file:///<PFAD_ZU_PLUGIN>/<PLUGIN.ZIP>

Um ein Plugin zu erneuern, muss es zuerst deinstalliert um danach installiert zu werden.
Die Deinstallation erfolgt mit den Befehlen von oben, allerdings mit dem Schalter -remove.

Dient dem Zugriff von verschiedenen Tools, wie z.B. Kibana, elasticHQ, logstash,…
Einstellungen in der elasticsearch.yml

http.cors.enabled: true
#http.cors.allow-origin: http://<HOSTNAME>.<DOMAINNAME>.<TLD>
#http.cors.allow-origin: /https?:\/\/(.*)?<DOMAINNAME>\.<TLD>(:[0-9]{1,5})?(/.*)?

Mit dem Parameter http.cors.allow-origin kann der zugriff von bestimmten URLs erlaubt/verweigert werden.
Siehe dazu die Doku von Elasticsearch.

Mit Templates lassen sich Einstellungen für Indices auf neu erstellte Indices ausrollen

• welche Indices gibt es

  curl -X PUT -k -u <USERNAME> "https://http://localhost:9200/_cat/templates?v&s=name"

Quelle: https://www.elastic.co/guide/en/elasticsearch/reference/master/index-lifecycle-management.html
Mit Lifecycle Policies automatisiert man verschiedene Management Aufgaben für Indices bzw. Snapshots.
Lifecycle Management für Indices werden IndexLifecycleManagement und für Snapshots SnapshotLifecycleManagement genannt.
Mit ilm kann man z.B. steuern, dass ein neuer Index erstellt wird, wenn ein bestehender eine bestimmte Größe erreicht hat.
Oder man löscht einen Index autom. nach x Tagen.

Es gibt 4 Policy-Stufen, wleche die Reihenfolge der Ausführung einer Policy steuern.

Die 4 Stufen können folgende Actionen verarbeiten.

ilm

• welche Policies gibt es:

  curl -XGET -k -u <USERNAME> https://localhost:9200/_ilm/policy?pretty

• Status des ilm ausgeben

  curl -X GET -k -u <USERNAME> "https://localhost:9200/_ilm/status"

• starten/stoppen des ilm

  curl -X POST -k -u <USERNAME> "https://localhost:9200/_ilm/[start|stop]"

• Policy erstellen (z.B. zum Löschen nach 30 Tagen):

  curl -X PUT -k -u <USERNAME> "https://localhost:9200/_ilm/policy/<NAME>_policy" -H 'Content-Type: application/json' -d'
  {
    "policy" : {
      "phases" : {
        "delete" : {
          "min_age" : "30d",
            "actions" : {
              "delete" : { }
          }
        }
      }
    }
  }
  '

• Policy in Template bereitstellen und somit auf neue Indices namens „logstash-*“:

  curl -X PUT -k -u <USERNAME> "https://localhost:9200/_template/<NAME>_template" -H 'Content-Type: application/json' -d'
  {
    "index_patterns": ["logstash-*"],                 
    "settings": {
      ...,
      "index.lifecycle.name": "<NAME>_policy",      
    }
  }
  '

• Welche Policies sind auf Indices bereitgestellt:

  curl -X GET -k -u <USERNAME> "https://localhost::9200/logstash-*/_ilm/explain?pretty"

• Policy zu bestehenden Indices hinzufügen

  curl -X PUT -k -u <USERNAME> "https://localhost:9200/<NAME>_index/_settings" -H 'Content-Type: application/json' -d'
  {
    "lifecycle.name": "<NAME>_policy"
  }
  '

• zum Updaten einer bestehenden Policy, muss diese einfach mit den neuen Werten überschrieben werden.
  Die Policy-Version wird dann um den Wert „1“ angehoben und die Indices, welche die Policy zugewiesen haben ebenfalls aktualisiert

slm

• mit slm kann man Indices autom. sichern oder wiederherstellen: siehe https://www.elastic.co/guide/en/elasticsearch/reference/master/getting-started-snapshot-lifecycle-management.html

Hier einige Befehle die an ES übergeben werden können.
Damit die Ausgabe der Befehle auch lesbar ist, sollte man möglichst folgendes am Ende der http-Adresse eingeben ?pretty=true

Für alle Nodes im Cluster

curl -XGET -k -u <USERNAME> 'https://localhost:9200/_nodes?pretty=true'

Nur für den lokalen Node

curl -XGET -k -u <USERNAME> 'https://localhost:9200/_nodes/_local?pretty=true'

curl -X PUT -k -u <USERNAME> "https://localhost:9200/Index-000002" -H 'Content-Type: application/json' -d'
{
  "aliases": {
    "test-alias2":{
      "is_write_index": true 
    }
  }
}
'

curl -XGET -k -u <USERNAME> 'https://localhost:9200/_cat/indices?v'

• öffnen
  

  curl -XPOST -k -u <USERNAME> 'https://localhost:9200/my_index/_open'

• schließen
  

  curl -XPOST -k -u <USERNAME> 'https://localhost:9200/my_index/_close'

• zum Anzeigen der geschlossenen Indexe
  

  curl -k -u <USERNAME> "https://localhost:9200/_cluster/state/blocks?pretty"

curl -XGET -k -u <USERNAME> 'https://localhost:9200/<INDEXNAME>/_settings'

curl -XPOST -k -u <USERNAME> 'https://localhost:9200/<INDEXNAME>/_refresh'

curl -XGET -k -u <USERNAME> 'https://localhost:9200'

curl -XGET -k -u <USERNAME> 'https://localhost:9200/_cluster/health?pretty=true'

Hier ein noch ausführlicherer Befehl

curl -XGET -k -u <USERNAME> 'https://localhost:9200/_nodes?os=true&process=true&pretty=true'

Zum Ein- und Ausschalten von Shard-Balancing (z.B. für Wartungen an einem Node) folgender Befehl

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d'{"<transient|persistent>":{"cluster.routing.allocation.enable": <all|primaries|new primaries|none>}}'

http://elasticsearch-host:port/index-name/index-type/_search?q=<SUCHTEXT>
oder
http://elasticsearch-host:9200///_search?q=<SUCHTEXT>&pretty
oder über die o.g. Plugins.

Zum ausgeben von aktuellen Einstellungen des Elasticsearch-Clusters benutzt man folgenden Befehl.

curl -XGET -k -u <USERNAME> https://localhost:9200/_cluster/settings?pretty

oder hier die Cluster-Einstellungen mit Default-Einstellungen

curl -XGET -k -u <USERNAME> https://localhost:9200/_cluster/settings?pretty&include_defaults

Um Einstellungen abzusetzen wählt man folgende Befehlssyntax.

• transient: vorübergehende Einstellung (wrid nach dem nächsten Starten von Elasticsearch wieder mit dem dauerhaft eingestellten Wert überschrieben
• persistent: dauerhafte Änderung der Einstellung in Elasticsearch

curl -XPUT -k -u <USERNAME> https://localhost:9200/_cluster/settings -H 'Content-Type: application/json' -d '{
    "<transient>|<persistent>" : {
        "<BEFEHL>" : "<WERT>"
    }
}'

Hier ein Beispiel um einen Node aus dem Cluster zu ignorieren

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{
    "transient" : {
        "cluster.routing.allocation.exclude._ip" : "10.0.0.1"
    }
}'

Um die Anzahl an Master-Nodes zu ändern folgender Befehl
persistent

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{
    "persistent" : {
        "discovery.zen.minimum_master_nodes" : 2
    }
}'

transient

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{
    "transient" : {
        "discovery.zen.minimum_master_nodes" : 2
    }
}'

Um das ZEN Discovery auszuschalten, nutzt man folgenden Befehl

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_cluster/settings?pretty=true' -H 'Content-Type: application/json' -d '{transient: {"discovery.zen.ping.multicast.ping.enabled": false}}'

curl -XPOST -k -u <USERNAME> https://localhost:9200/<INDEX_NAME>[*]/_refresh

curl -XPOST -k -u <USERNAME> https://localhost:9200/<INDEX_NAME>[*]/_close

curl -XDELETE -k -u <USERNAME> https://localhost:9200/<INDEX_NAME>[*]

Quelle: www.elastic.co
Bei ES Version 1.x gibt es mittlerweile das Modul „Snapshot and Restore“.

Dieses Modul erlaubt es einfache und schnelle Datensicherungen des Clusters oder einzelner Elemente auf ein Repository zu erstellen.
Ein Repository kann ein Mountpoint oder andere Systeme wie Amazon S3, HDFS oder MS Azure sein.
Im Weiteren wird hier nur auf einen Mountpoint eingegangen.

zunächst erstellt man sich ein neues Repository zum sichern der Daten.
Als Parameter werden übergeben:

• Backupname: my_backup
• Typ: fs (filesystem)
• Location: /datensicherung (Mountpoint)
• max_snapshot_bytes_per_sec: 50mb (max. Übertragungsrate bei Snapshot)
• max_restore_bytes_per_sec: 50mb (max. Übertragungsrate bei Restore)

XPUT _snapshot/my_backup 
{
    "type": "fs", 
    "settings": {
        "location": "/mount/backups/my_backup",
        "max_snapshot_bytes_per_sec" : "50mb", 
        "max_restore_bytes_per_sec" : "50mb"
    }
}

Wenn man Änderungen am Repository machen möchte muss ein „POST“ anstatt eines „PUT“ angewandt werden. Beispiel: Hinzufügen der Kompression.

XPOST _snapshot/my_backup/
{
    "type": "fs", 
    "settings": {
        "location": "/mount/backups/my_backup",
        "max_snapshot_bytes_per_sec" : "50mb", 
        "max_restore_bytes_per_sec" : "50mb",
        "compress" : true 
    }
}

Zum Anzeigen des angelegten Repositories führt man folgenden Befehl aus:

XGET /_snapshot/my_backup

oder

XGET /_snapshot

oder

XGET /_snapshot/_all

Zum Prüfen folgender Befehl:

XPOST /_snapshot/my_backup/_verify

Zum löschen eines Repositories verwendet man:

XDELETE /_snapshot/my_backup

Beim ersten Snapshot wird eine Kopie aller Daten des Clusters erstellt. Danach werden nur die anfallenden Daten gesichert.

Man kann nun einen Snapshot namens „snap1“ nun folgendermaßen erstellen:

XPUT /_snapshot/my_backup/snap1?wait_for_completion=false

Der Parameter „wait_for_completion=false“ sagt aus, dass die Ausgabe des Befehls sofort erfolgen soll. Bei großen Repositories ist die vorteilhaft, da dann der Client nicht blockiert wird.

Mit dem o.g. Befehl erstellt man einen vollständigen Snapshot von allen Indices des Cluster.
Möcht man nur bestimmte Indices sichern, kann man dies wie folgt anweisen:

XPUT /_snapshot/my_backup/snap1
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": true
}

Hierbei (ignore_unavailable) werden auch nicht mehr vorhandene Indices ignoriert. Wenn dieser Parameter auf „false“ steht, wird der Snapshot bei fehlenden Indices fehlschlagen.
Weiterhin weisen wir an, dass im Snapshot der globale Status des Clusters mit gesichert wird. So werden Einstellungen des Cluster auch gesichert.
Wenn es Indices gibt welche keine „primary Shard“ haben, wird auch hier der Snapshot fehlschlagen. Dies kann mit dem folgenden Paramter unterbunden werden:

"partial" : true

Informationen über erstellte Snapshot holt man sich mit folgenden Befehlen:

XGET /_snapshot/my_backup/snap1

oder

XGET /_snapshot/my_backup/_all

Den Status erhält man mit:

XGET /_snapshot/_status

oder

XGET /_snapshot/my_backup/_status

oder

XGET /_snapshot/my_backup/snap1/_status

oder

XGET /_snapshot/my_backup/snap1,snap2/_status

Zum löschen eines Snapshots verwendet man:

XDELETE /_snapshot/my_backup/snap1

Wenn man einen großen Snapshot aus versehen angestoßen hat, kann man diesen mit dem DELETE-Befehl abbrechen. Die bis dahin erstellten Daten werden bereinigt.

#!/bin/bash
 
# Script to Backup Elasticsearch
# scripted by stizi.de
 
#Colors
red=`tput setaf 1`
green=`tput setaf 2`
reset=`tput sgr0`
 
ES_URL='http://localhost:9200'
REPO_LOCATION='/data/snapshots'
SNAPNAME=`date +%Y%m%d`
# Backups older than LIMIT (hiere in Days)
LIMIT=30
 
#-------------- no changes from here --------------#
 
ES_VERSION=`curl -s -XGET "${ES_URL}"|jq -r ".version.number"`
SNAPSHOTS=`curl -s -XGET "${ES_URL}/_snapshot/${ES_VERSION}/_all"`
REPOSITORIES=`curl -s -XGET "${ES_URL}/_cat/repositories"|awk '{print $1}'`
 
##Checking Environment for Snapshotting
# checking Repo Location
check_repo_location()
{
  echo -n "checking Location of Repository..."
  if [ ! -d "${REPO_LOCATION}" ]; then
    echo "...${red}FAILED${reset}"
    echo "Location for Repository \"${REPO_LOCATION}\" does ${red}not exists${reset}."
    echo "Please create a Location for Repository and edit Parameter \"REPO_LOCATION\"."
    exit 1;
  else
    echo "...${green}OK${reset}"
  fi
}
 
# cecking mountpoint
check_mountpoint()
{
  echo -n "checking Repository Mountpoint..."
  grep ${REPO_LOCATION} /etc/fstab > /dev/null
  if [ $? -eq 0 ]; then
    echo "...${green}OK${reset}"
  else
    echo "...${red}FAILED${reset}"
    echo "Mountpoint not configured in fstab."
    exit 1;
  fi
 
  grep ${REPO_LOCATION} /etc/mtab > /dev/null
  if [ $? -eq 0 ]; then
    echo "Location for Repository exits and is ${green}mounted${reset}."
  else
    echo "Location for Repository exits but is ${red}not mountet${reset}."
    echo "mounting Location..."
    mount ${REPO_LOCATION}
    if [ $? -ne 0 ]; then
      echo "mounting ${red}FAILED${reset}."
      exit 1;
    fi
  fi
}
 
#checking Repo in ES
check_repo_es()
{
  echo -n "checking if Repository exists in ES..."
  curl -s -XGET "${ES_URL}/_snapshot/_all"|grep ${ES_VERSION} > /dev/null
  if [ $? -eq 0 ]; then
    echo "...${green}OK${reset}"
  else
    echo "...${red}FAILED${reset}"
    echo "Repository does not exits, trying to create Repository..."
    curl -s -XPUT "${ES_URL}/_snapshot/${ES_VERSION}" -H 'Content-Type: application/json' -d'{"type": "fs", "settings": {"location": "'${REPO_LOCATION}'"}}' > /dev/null
    if [ $? -eq 0 ]; then
      echo "new Repository: ${green}${ES_VERSION}${reset}. Verified by..."
      curl -s -XPOST "${ES_URL}/_snapshot/${ES_VERSION}/_verify?pretty"
    else
      echo "creating Repository ${red}FAILED${reset}."
      exit 1;
    fi
  fi
}
 
##Let's Go...
 
case "$1" in
  backup)
    check_repo_location
    check_mountpoint
    check_repo_es
    curl -s -XPUT "${ES_URL}/_snapshot/${ES_VERSION}/${SNAPNAME}?wait_for_completion=true"
    returncode=$?
    ;;
 
  clean)
    SNAPDEL=`echo ${SNAPSHOTS} | jq ".snapshots[].snapshot"`
    DATE_DEL_FROM=`date +%s000 -d "${LIMIT} day ago"`
    echo "trying to delete Snapshots from Repository ${ES_VERSION} older than ${LIMIT} Days..."
    for SNAPNAME in ${SNAPDEL}
      do
        SNAP_START=`echo ${SNAPSHOTS}| jq  ".snapshots[] | select( .snapshot == ${SNAPNAME}).start_time_in_millis"`
        if [ ${SNAP_START} -lt ${DATE_DEL_FROM} ]; then
          echo -n "Deleting snapshot: ${SNAPNAME}"
          curl -s -XDELETE "${ES_URL}/_snapshot/${ES_VERSION}/${SNAPNAME//\"/}"
          returncode=$?
          if [ $? -eq 0 ]; then
            echo "...${green}DELETED${reset}"
          else
            echo "...${red}FAILED${reset}"
          fi
          echo ""
        fi
      done
    echo "Cleaning Job done!"
    ;;
 
 showsnaps)
    for REPONUM in ${REPOSITORIES}
      do
        echo "Snapshots in Repository ${REPONUM}:"
        curl -s -XGET "${ES_URL}/_snapshot/${REPONUM}/_all"|jq ".snapshots[].snapshot"
      done
    ;;
 
  *)
    echo ""
    echo "Usage: $0 {backup|clean|showsnaps}"
    echo ""
    returncode=1
 
  esac
exit $returncode

Um einen Snapshot wiederherzustellen führt man folgenden Befehl aus:

XPOST /_snapshot/my_backup/snap1/_restore

Hierbei wird der gesamte Stand des Snapshots wiederhergestellt.
Wenn nur einzelne Teile des Snapshots wiederhergestellt werden sollen, kann man dies wie folgt anweisen:

XPOST /_snapshot/my_backup/snap1/_restore
{
  "indices": "index_1,index_2",
  "ignore_unavailable": "true",
  "include_global_state": false,
  "rename_pattern": "index_(.+)",
  "rename_replacement": "restored_index_$1"
}

Auch beim Restore kann man wieder nur partielle Shards wiederherstellen mit:

"partial" : true

Beim Restore können auch Einstellungen der Indices angepasst werden.
Beispiel: Index wiederherstellen ohne Replicas:

XPOST /_snapshot/my_backup/snap1/_restore
{
  "indices": "index_1",
  "index_settings": {
    "index.number_of_replicas": 0
  },
  "ignore_index_settings": [
    "index.refresh_interval"
  ]
}

Man kann einen Snapshot auch auf einem anderen Cluster wiederherstellen.
Vorher sollte man aber darauf achten, dass die Speicherkapazität des neuen Clusters der des Snapshots entspricht. Weiterhin sollte die Version des neuen Clusters mindestens gleich wenn nicht größer sein als die des Clustern welcher den Snapshot erstellt hat.

Wenn ein großer Snapshot oder Restore erstellt wird, kann man sich den aktuellen Status anzeigen lassen. Wichtig ist nur dass man die Befehle für Snapshot oder Restore mit dem Parameter „wait_for_completion“ auf „true“ versehen hat, sonst wird ja der Client beim Snapshotten oder Restoren blockiert.
Der Befehl zum Monitoren lautet:

XGET /_snapshot/my_backup/snapshot_1

Ausführlichere Informationen erhält man mit folgendem Befehl:

XGET /_snapshot/my_backup/snapshot_1/_status

Die Datensicherung erfolgt bei einem local Gateway und z.B. einem node in folgenden Schritten:

1. Erstes (und einziges) Full-Backup per rsync (Da die ES noch läuft und weiter Fleissig Indices schreibt ist das eine inkonsistente Datensicherung)
2. nun stoppt man das „refreshing“ der Datenbank in die Indices
3. nach dem Stoppen refresht man nun einen letzten Stand
4. jetzt kann wieder mit rsync eine Datensicherung gemacht werden (Nun inkrementell und konsistent)
5. nach der DaSi startet mann wieder dass „refreshing“

#!/bin/bash
 
# Datensicherungsziel OHNE abschliessenden Slash
DEST="<PFAD_ZUM_SICHERUNGSZIEL>"
SRC="<PFAD_ZUR_DATENBANKQUELLE>"
 
#### Ab hier Finger weg, wenn keine Ahnung ####
 
# binary Pfade
CMDHOSTNAME=`which hostname`
CMDMOUNT=`which mount`
CMDUMOUNT=`which umount`
CMDCURL=`which curl`
CMDRSYNC=`which rsync`
 
# Timestamp fuer logging
LOGTS="$(date "+%b %d %Y %H:%M:%S")"
RSYNCLOG="${DEST}/ES/rsync.log"
ESLOG="${DEST}/ES/es.log"
 
# Rsync Stuff
RSYNCOPTS="-a -A -X --stats --ignore-existing --progress --exclude="lost+found" --log-file=${RSYNCLOG}"
 
#
# Mount Check
#
ERROR=0
if grep -qs "${DEST}" /proc/mounts; then
        echo "${LOGTS} ${DEST} is mounted."
 
        if touch "${DEST}/test.touch" 2>/dev/null; then
                rm "${DEST}/test.touch"
                echo "${LOGTS} ${DEST} is writeable."
        else
          echo "${LOGTS} WARNUNG: Ziel nicht beschreibbar."
                 ERROR="1"
        fi
 
else
        echo "${LOGTS} WARNUNG: Ziel nicht gemounted."
        ERROR=1
fi
 
if [ ${ERROR} != 0 ]; then
        echo "${LOGTS} WARNUNG: Versuche mount!"
        ${CMDUMOUNT} ${DEST} 2>/dev/null
        ${CMDMOUNT} ${DEST}
 
        if touch "${DEST}/test.touch" 2>/dev/null; then
                rm "${DEST}/test.touch"
                echo "${LOGTS} It's writeable."
        else
                echo "${LOGTS} WARNUNG: Ziel immer noch nicht beschreibbar."
                #mail
                exit 1
        fi
 
fi
 
 
#
# disable Refreshing
#
echo "${LOGTS} disableing flush Operations" > ${ESLOG}
 
${CMDCURL} -XPUT 'localhost:9200/_settings' -H 'Content-Type: application/json' -d '{
"index" : {
"translog.disable_flush" : "'true'"
}
}' > ${ESLOG}
 
echo ""
 
echo "${LOGTS} refreshing disabled" > ${ESLOG}
 
#
# Refresh one last time
#
echo "${LOGTS} refreshing once more" >${ESLOG}
 
${CMDCURL} -XPOST 'localhost:9200/_refresh'  > ${ESLOG}
 
echo ""
 
echo "${LOGTS} Indices refreshed " > ${ESLOG}
 
#
# Backup Database
#
echo "${LOGTS} rsyncing ES" > ${ESLOG}
 
${CMDRSYNC} ${RSYNCOPTS} ${SRC} ${DEST} 1>> ${RSYNCLOG} 2>&1
 
echo "${LOGTS} rsyncing ES finished" > ${ESLOG}
 
#
# enable Refreshing
#
echo "${LOGTS} starting refreshing" > ${ESLOG}
 
${CMDCURL} -XPUT 'localhost:9200/_settings' -H 'Content-Type: application/json' -d '{
"index" : {
"translog.disable_flush" : "'false'"
}
}' > ${ESLOG}
 
echo ""
 
echo "${LOGTS} refreshing enabled" > ${ESLOG}
 
#
# Print Index Settings
#
curl -XGET 'localhost:9200/_settings?pretty=true'|grep 'index.translog.disable_flush' > ${ESLOG}

Updates können ganz leicht über .deb Pakete installiert werden.
Man kann auch eine Paketquelle angeben.

Zuerst fügt man den GPG-Key hinzu:

wget -O - http://packages.elasticsearch.org/GPG-KEY-elasticsearch | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/elastic.gpg  >/dev/null

Nun noch einen Eintrag in die Paketquelllisten (Für alle 0.90.x Versionen trägt man „0.90“, für alle 1.0.x Versionen trägt man „1.0“ ein):

deb http://packages.elasticsearch.org/elasticsearch/0.90/debian stable main

• Elasticsearch

  curl -k -u <USERNAME> -X PUT "https://localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
  {
    "persistent": {
      "cluster.routing.allocation.enable": "primaries"
    }
  }
  '
   
  curl -k -u <USERNAME> -X POST "https://localhost:9200/_flush/synced?pretty"
   
  systemctl stop elasticsearch.service
   
  dpkg -i ...deb
   
  systemctl start elasticsearch.service
   
  curl -k -u <USERNAME> -X GET "https://localhost:9200/_cat/nodes?pretty"
   
  curl -k -u <USERNAME> -X PUT "https://localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
  {
    "persistent": {
      "cluster.routing.allocation.enable": null
    }
  }
  '
   
  curl -k -u <USERNAME> -X GET "https://localhost:9200/_cat/health?v&pretty"

vi /etc/elasticsearch/elasticsearch.yml

Hier folgenden Parameter prüfen (Standardwert ist: 65535)

MAX_OPEN_FILES

Quelle: Elasticsearch-Setup-Guide

Weiterhin kann noch der „nofile“ Wert in den Security-Einstellungen, für den Benutzer unter dem der Elasticsearch-Prozess läuft, angepasst werden.

vi /etc/security/limits.conf

Hier folgendes unten eintragen

elasticsearch soft nofile 9000
elasticsearch hard nofile 65000

Hiernach noch die folgende Datei anpassen:

vi /etc/pam.d/common-session

Inhalt unten einfügen

# For Elasticsearch max File open Limit
session required                        pam_limits.so

Nach einem Reboot kann man die neuen Wert mit diesem Befehl testen

ulimit -a

oder nur für die „open files“

ulimit -n

Wichtig man hat hier nur die Werte für den Benutzer „elasticsearch“ geändert nicht für alle Benutzer.
Um den aktuellen Wert sofort zu setzen, benutzt man den o. g. Befehl mit dem Parameter für den neuen Wert

Beispiel:

ulimit -n 9000

Quelle: Elasticsearch-Tutuorials

Wenn Shards, den Nodes nicht zugewiesen sind, kann man mit diesem Befehl sich den Status und den Grund dieser Shards angzeigen lassen

curl -XGET -k -u <USERNAME> https://localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason| grep UNASSIGNED

Eine andere Möglichkeit sich das gesamt vom Cluster aus zu zeigen ist:

curl -XGET -k -u <USERNAME> https://localhost:9200/_cluster/allocation/explain?pretty

Mit folgenden Befehlen kann dies berichtigt werden.

Ausführlicher Befehl zum Zuordnen von bestimmten Shards aus bestimmten Indexen zu bestimmten Nodes.

for i in 0 1 2 3 4; do curl XPOST -s -k -u <USERNAME> 'https://http://localhost:9200/_cluster/reroute?pretty=true' -H 'Content-Type: application/json' -d '{ "commands" : [ { "allocate" : { "index" : "<INDEX_NAME>", "shard" : <SHARD_NUMBER><ODER>'$i' , "node" : "<NODE_NAME>", "allow_primary" : <0|1> }}]}'; done

Rerouting von Shards mit der Einstellung index.routing.allocation.enable:

• auf einen bestimmten Index

  curl -XPUT -k -u <USERNAME> 'https://localhost:9200/<index>/_settings' -H 'Content-Type: application/json' -d ' {"index.routing.allocation.enable": "none"}'

• oder auf einen Node

  curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_settings' -H 'Content-Type: application/json' -d ' {"index.routing.allocation.enable": "none"}'

Um alle Shards von allen Indexen zuzuweisen, kann dieses Script genutzt werden.
Hier muss mann nur noch in der Variable „INDEX“ angeben welche Indexe man sehen will (den „grep“ Befehl anpassen) und danach noch der geschachtelte „for“-Schleife sagen wieviele Shards sie durchlaufen soll:

#!/bin/bash
#
#
#
curl -XGET -k -u <USERNAME> 'https://localhost:9200/_cluster/state/nodes?pretty'|grep -B1 name
read -p "Internal_Node_ID:" NODE
#NODE="<NODE_NAME>"
 
#read -p "Elasicsearch Index:" INDEX
INDEX=`curl -XGET -k -u <USERNAME> https://localhost:9200/_cat/indices?v|grep -v yellow|awk '{print $3}'`
 
for line in $INDEX; do
  for ((i=0;i<=4;i++)); do
    curl -XPOST -k -u <USERNAME> 'https://localhost:9200/_cluster/reroute' -H 'Content-Type: application/json' -d '{"commands":[{"allocate":{"node":"'${NODE}'", "allow_primary": true, "index":"'${line}'", "shard":'$i'}}]}'
  done
done

Normalerweise sollten Shards mehrere Replikate haben. Damit man im Ausfall eines Nodes noch Daten auf anderen Nodes vorhalten kann.
Mit diesen Befehlen kann man das Verhalten steuern.
Replikate für einen bestimmten Index ändern (hier auf 1 Replikat):

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/<INDEXNAME>/_settings' -H 'Content-Type: application/json' -d '{"index.number_of_replicas":1}'

Replikate für alle Indexe ändern (hier auf 0 Replikate):

curl -XPUT -k -u <USERNAME> 'https://localhost:9200/_settings' -H 'Content-Type: application/json' -d '{"index.number_of_replicas":0}'

Ab der Elasticsearch Version 1.4 müssen für den Zugriff von verschiedenen externen Programmen (z.B. Kibana, elasticHQ, logstash) noch diese Parameter in der
/etc/elasticsearch/elasticsearch.yml gesetzt werden.

####### Connection settings in Elasticsearch 1.4 #######
http.cors.enabled: true
#http.cors.allow-origin: http://<HOSTNAME>.<DOMAINNAME>.<TLD>
#http.cors.allow-origin: /https?:\/\/(.*)?<DOMAINNAME>\.<TLD>(:[0-9]{1,5})?(/.*)?

Mit dem Parameter http.cors.allow-origin kann der zugriff von bestimmten URLs erlaubt/verweigert werden.
Siehe dazu die Doku von Elasticsearch.