====== 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 ===== Installation ===== 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-.deb dpkg -i elasticsearch-.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 ===== starten und prüfen ===== 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. ==== Daten- und Logverzeichnis ==== Standardmäßig legt Elasticsearch seine Datenbank unter folgendem Pfad ab: ''/var/lib/elasticsearch//node/'' 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: # Elasticsearch data directory path.data: 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 chown -R elasticsearch.elasticsearch 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 https://localhost:9200 Die Anwort sollte ungefähr dies ausgeben. { "name" : "", "cluster_name" : "", "version" : { "number" : "", "build_hash" : "", "build_timestamp" : "", "build_snapshot" : false, "lucene_version" : "" }, "tagline" : "You Know, for Search" } Hier noch Befehle zum Status des Clusters und des gestarteten Nodes: **Global Health** \\ curl -k -u https://localhost:9200/_cat/health?v **Clusterinfo** \\ curl -k -u https://localhost:9200/_cat/cluster?v **Nodeinfo** \\ curl -k -u https://localhost:9200/_cat/nodes?v ==== Debugging ==== * **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 ''//.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 "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 "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" } ' ===== Netzwerkeinstellungen ===== 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: Oder so: network.bind_host: network.publish_host: Folgende Angaben können zu den Parametern ''network.bind_host'' und ''network.publish_host'' verwendet werden (Quelle: [[https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html|www.elastic.co]]): ^ Logical Host Setting Value ^ Description ^ | _local_ | Will be resolved to loopback addresses | | _local:ipv4_ | Will be resolved to loopback IPv4 addresses | | _local:ipv6_ | Will be resolved to loopback IPv6 addresses | | _non_loopback_ | Addresses of the first non loopback interface | | _non_loopback:ipv4_ | IPv4 addresses of the first non loopback interface | | _non_loopback:ipv6_ | IPv6 addresses of the first non loopback interface | | _[networkInterface]_ | Resolves to the addresses of the provided network interface. For example _en0_. | | _[networkInterface]:ipv4_ | Resolves to the ipv4 addresses of the provided network interface. For example _en0:ipv4_. | | _[networkInterface]:ipv6_ | Resolves to the ipv6 addresses of the provided network interface. For example _en0:ipv6_. | Diese Einstellungen sollten in den jew. Modulen, z.B. im HTTP-Modul (siehe [[#Module]]) auch angepasst werden. ===== Cluster ===== 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. ==== Cluster-Einstellungen ==== * "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 '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 '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 '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 'https://localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d' {"transient":{"indices.recovery.max_bytes_per_sec":null}}' ==== Cluster mit 1 Data-Node ==== 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 '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. ==== Cluster mit mehr als 1 Node ==== 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 [[https://www.elastic.co/guide/en/elasticsearch/reference/5.6/modules-cluster.html|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. ^ Dynamisch \\ Updatebar ^ Node 1 ^ Node2 ^ Beschreibung ^ ^ Nodetype ^ ^ ^ Gibt den Typ des Nodes an (Master/Data/ingest/tribe.*) ^ | | ''node.master'' true | ''node.master'' true | (true/false) Node als Master-Node setzen | | | ''node.data'' true | ''node.data'' true | (true/false) Node als Daten-Node setzen | ^ Shard Allocation Settings ^ ^ ^ Einstellungen zum Zuweisen und zum Verschieben von Shards innerhalt eines Clusters ^ | x | ''cluster.routing.allocation.enable'' all | ''cluster.routing.allocation.enable'' all | (all/primaries/new_primaries/none) Shard-Zuweisung einschalten | | x | ''#cluster.routing.allocation.node_concurrent_incoming_recoveries'' 2 | ''#cluster.routing.allocation.node_concurrent_incoming_recoveries'' 2 | (Anzahl) Wieviele eingehende Wiederherstellungsshards können den Node gleichzeitig erreichen | | x | ''#cluster.routing.allocation.node_concurrent_outgoing_recoveries'' 2 | ''#cluster.routing.allocation.node_concurrent_outgoing_recoveries'' 2 | (Anzahl) Wieviele ausgehende Wiederherstellungsshards können vom Node gleichzeitig gesandt werden | | x | ''cluster.routing.allocation.node_concurrent_recoveries'' 2 | ''cluster.routing.allocation.node_concurrent_recoveries'' 2 | (Anzahl) Einstellung um die zwei zuvor genannten Einstellungen zusammenzufassen | | x | ''cluster.routing.allocation.node_initial_primaries_recoveries'' 4 | ''cluster.routing.allocation.node_initial_primaries_recoveries'' 4 | (Anzahl) Wieviele Primäre Shards sollen lokal von der Festplatte und über das Netzwerk, nach einem neustart wiederhergestellt werden; je höher desto schneller | | x | ''cluster.routing.allocation.same_shard.host'' false | ''cluster.routing.allocation.same_shard.host'' false | (true/false) Läst Prüfungen zu, welche verhindern, dass mehrfache Instanzen einer Shard auf einem Host (wenn mehrere Nodes auf einem Host laufen) zugewiesen werden können | ^ Shard Rebalancing Settings ^ ^ ^ Einstellungen zum Verteilen der Shards per Node innerhalb eines Clusters ^ | x | ''cluster.routing.rebalance.enable'' all | ''cluster.routing.rebalance.enable'' all | (all/primaries/replicas/none) Shard-Rebalancing für sprezifische Shards einschalten | | x | ''cluster.routing.allocation.allow_rebalance'' indices_all_active | ''cluster.routing.allocation.allow_rebalance'' indices_all_active | (allways/indices_primaries_active/indices_all_active) Wann sollen Shards rebalanced werden | | x | ''cluster.routing.allocation.cluster_concurrent_rebalance'' 2 | ''cluster.routing.allocation.cluster_concurrent_rebalance'' 2 | (Anzahl) Wieviele Shards können gleichzeitig im Cluster rebalanced werden | ^ Shard Balancing Heuristics ^ ^ ^ Einstellungen zur Heuristik des Verteilens von Shards innerhalb eines Clusters ^ | x | ''cluster.routing.allocation.balance.shard'' 0.45f | ''cluster.routing.allocation.balance.shard'' 0.45f | Gewichtungsfactor zum Balancing der zugewiesenen Anzahl von Shards per Node; je höher, desto ausgeglichener ist die Verteilung | | x | ''cluster.routing.allocation.balance.index'' 0.55f | ''cluster.routing.allocation.balance.index'' 0.55f | Gewichtungsfactor zum Balancing der zugewiesenen Anzahl von Shards pro Index per Node; je höher, desto ausgeglichener ist die Verteilung | | x | ''cluster.routing.allocation.balance.threshold'' 1.0f | ''cluster.routing.allocation.balance.threshold'' 1.0f | Factor zur optimierung des Balancing im Cluster; je höher, desto weniger agressiv wird das Balancing ausgeführt | ^ Disk-based Shard Allocation ^ ^ ^ Einstellungen zum hinzuziehen des lokalen Festplattenspeicherplatzes eines Nodes, ob Shards verteilt oder verteilte Shards angenommen werden sollen ^ | x | ''cluster.routing.allocation.disk.threshold_enabled'' true | ''cluster.routing.allocation.disk.threshold_enabled'' true | (true/false) Festplattenspeicherplatz beim Zuweisen von Shards beachten, einschalten | | x | ''cluster.routing.allocation.disk.watermark.low'' 10gb | ''cluster.routing.allocation.disk.watermark.low'' 10gb | (%/gb/mb) Shard werden an einen Node, mit überschreitung dieser Schwelle, nicht weitergeleitet | | x | ''cluster.routing.allocation.disk.watermark.high'' 5gb | ''cluster.routing.allocation.disk.watermark.high'' 5gb | (%/gb/mb) Shard werden von diesem Node, mit überschreitung dieser Schwelle, an andere Nodes weitergeleitet | | x | ''cluster.info.update.interval'' 1m | ''cluster.info.update.interval'' 1m | (m) Wie oft soll der Festplattenspeicherplatz überprüft werden | | x | ''cluster.routing.allocation.disk.include_relocations'' true | ''cluster.routing.allocation.disk.include_relocations'' true | (true/false) Shard-Zuweisung zur Prüfung des Festplattenspeicherplatz hinzuziehen | ^ Miscellaneous cluster settings ^ ^ ^ Verschiedene Einstellungen für den gesamten Cluster ^ | x | ''cluster.blocks.read_only'' false | ''cluster.blocks.read_only'' false | (true/false) versetzt den gesamten Cluster in nur lesenden Zugriff | | x | ''cluster.blocks.read_only_allow_delete'' false | ''cluster.blocks.read_only_allow_delete'' false | (true/false) versetzt den gesamten Cluster in nur lesenden Zugriff, wobei löschvorgänge dennoch ausgeführt werden können | ^ Discovery ^ ^ ^ Einstellungen zum suchen von Nodes innerhalb eines Clusters ^ | | ''cluster.name'' cluster-stizi | ''cluster.name'' cluster-stizi | setzt den Namen des Clusters; kann zum Gruppieren von verschiedenen Nodes verwendet werden | ^ Zen Discovery ^ ^ ^ Einstellungen von Zen-Discovery ^ | | ''discovery.zen.ping.unicast.hosts'' 10.0.0.1 | ''discovery.zen.ping.unicast.hosts'' 10.0.0.2 | ([, ]) Listet die Masternodes auf, welche im cluster zufinden sind | | | ''discovery.zen.ping.unicast.hosts.resolve_timeout'' 5s | ''discovery.zen.ping.unicast.hosts.resolve_timeout'' 5s | (s) Zeit zum warten der DNS-Auflösung | | | ''discovery.zen.minimum_master_nodes'' 2 | ''discovery.zen.minimum_master_nodes'' 2 | (Anzahl) Anzahl der erwarteten Master-Nodes beim suchen | | | ''discovery.zen.no_master_block'' write | ''discovery.zen.no_master_block'' all | (all/write) Was soll abgewiesen werden (lesen und schreiben oder nur schreiben, wenn kein activer Master-Node im Cluster gefunden wurde | ^ Local Gateway ^ ^ ^ Speichert den Zustand des Clusters und der Shard daten während eines kompletten Cluster-Neustarts ^ | | ''gateway.expected_nodes'' 2 | ''gateway.expected_nodes'' 2 | (Anzahl) Wieviele Nodes (Master oder Data) werden im Cluster erwartet | | | ''gateway.expected_master_nodes'' 2 | ''gateway.expected_master_nodes'' 2 | (Anzahl) Wieviele Master-Nodes werden im Cluster erwartet | | | ''gateway.expected_data_nodes'' 2 | ''gateway.expected_data_nodes'' 2 | (Anzahl) Wieviele Data-Nodes werden im Cluster erwartet | | | ''gateway.recover_after_time'' 5m | ''gateway.recover_after_time'' 5m | (m) Wenn die erwarteten Anzahlen an Nodes nicht gefunden wird, wartet das Local-Gateway wie angegeben, um danach erneut zu prüfen | | | ''gateway.recover_after_nodes'' 2 | ''gateway.recover_after_nodes'' 2 | (Anzahl) Solange erneut suchen, bis die angegebene Anzahl an Nodes gefunden wurde | | | ''gateway.recover_after_master_nodes'' 2 | ''gateway.recover_after_master_nodes'' 2 | (Anzahl) Solange erneut suchen, bis die angegebene Anzahl an Master-Nodes gefunden wurde | | | ''gateway.recover_after_data_nodes'' 2 | ''gateway.recover_after_data_nodes'' 2 | (Anzahl) Solange erneut suchen, bis die angegebene Anzahl an Data-Nodes gefunden wurde | 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-${HOSTNAME}", "discovery.zen.join_timeout" : "3s", "discovery.zen.ping.unicast.hosts" : "", "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" : [, , ,...] ==== Node im Wartungsmodus (Maintenance) ==== **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|Balancing]]. curl -XPUT -k -u '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 'https://localhost:9200/_flush?pretty' Machine Learning Jobs hält man wie folgt an. curl -XPOST -k -u '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 'https://localhost:9200/_cat/nodes?pretty' Danach schaut man in welchem Status sich der Cluster befindet. curl -XGET -k -u "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 '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 'https://localhost:9200/_ml/set_upgrade_mode?enabled=false&pretty' ===== Plugins ===== Mit folgendem Befehl kann man sehen welche Plugins für Elasticsearch installiert sind. curl -k -u 'https://localhost:9200/_cat/plugins?v' oder /usr/share/elasticsearch/bin/elasticsearch-plugin list Man findet Plugins bei [[https://github.com|GitHub]]. Installiert werden sie mit folgendem Befehl: /usr/share/elasticsearch/bin/elasticsearch-plugin install file://// ==== Plugin-Update ==== 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''. ===== Module ===== ==== HTTP ==== 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://.. #http.cors.allow-origin: /https?:\/\/(.*)?\.(:[0-9]{1,5})?(/.*)? Mit dem Parameter ''http.cors.allow-origin'' kann der zugriff von bestimmten URLs erlaubt/verweigert werden. Siehe dazu die [[http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-http.html|Doku]] von Elasticsearch. ==== Templates ==== Mit Templates lassen sich Einstellungen für Indices auf neu erstellte Indices ausrollen * welche Indices gibt es curl -X PUT -k -u "https://http://localhost:9200/_cat/templates?v&s=name" ==== Lifecycle Management ==== 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 **I**ndex**L**ifecycle**M**anagement und für Snapshots **S**napshot**L**ifecycle**M**anagement 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. ^ Name ^ Beschreibung ^ | ''hot'' | The index is actively being written to | | ''warm'' | The index is generally not being written to, but is still queried | | ''cold'' | The index is no longer being updated and is seldom queried. \\ The information still needs to be searchable, but it’s okay if those queries are slower. | | ''delete'' | The index is no longer needed and can safely be deleted | Die 4 Stufen können folgende Actionen verarbeiten. ^ Stufe ^ Action ^ | ''hot'' | Set Priority \\ Unfollow \\ Rollover | | ''warm'' | Set Priority \\ Unfollow \\ Read-Only \\ Allocate \\ Shrink \\ Force Merge | | ''cold'' | Set Priority \\ Unfollow \\ Allocate \\ Freeze | | ''delete'' | Delete | ** ilm ** * welche Policies gibt es: curl -XGET -k -u https://localhost:9200/_ilm/policy?pretty * Status des ilm ausgeben curl -X GET -k -u "https://localhost:9200/_ilm/status" * starten/stoppen des ilm curl -X POST -k -u "https://localhost:9200/_ilm/[start|stop]" * Policy erstellen (z.B. zum Löschen nach 30 Tagen): curl -X PUT -k -u "https://localhost:9200/_ilm/policy/_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 "https://localhost:9200/_template/_template" -H 'Content-Type: application/json' -d' { "index_patterns": ["logstash-*"], "settings": { ..., "index.lifecycle.name": "_policy", } } ' * Welche Policies sind auf Indices bereitgestellt: curl -X GET -k -u "https://localhost::9200/logstash-*/_ilm/explain?pretty" * Policy zu bestehenden Indices hinzufügen curl -X PUT -k -u "https://localhost:9200/_index/_settings" -H 'Content-Type: application/json' -d' { "lifecycle.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]] ===== Befehle ===== 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'' ==== Node Infos ==== Für alle Nodes im Cluster curl -XGET -k -u 'https://localhost:9200/_nodes?pretty=true' Nur für den lokalen Node curl -XGET -k -u 'https://localhost:9200/_nodes/_local?pretty=true' ==== Index erstellen ==== curl -X PUT -k -u "https://localhost:9200/Index-000002" -H 'Content-Type: application/json' -d' { "aliases": { "test-alias2":{ "is_write_index": true } } } ' ==== Alle Indexe auflisten ==== curl -XGET -k -u 'https://localhost:9200/_cat/indices?v' ==== Index öffnen/schließen ==== * öffnen \\ curl -XPOST -k -u 'https://localhost:9200/my_index/_open' * schließen \\ curl -XPOST -k -u 'https://localhost:9200/my_index/_close' * zum Anzeigen der geschlossenen Indexe \\ curl -k -u "https://localhost:9200/_cluster/state/blocks?pretty" ==== Einstellungen der Indices abfragen ==== curl -XGET -k -u 'https://localhost:9200//_settings' ==== Refresh erzwingen ==== curl -XPOST -k -u 'https://localhost:9200//_refresh' ==== Version Abfragen ==== curl -XGET -k -u 'https://localhost:9200' ==== Status abfragen ==== curl -XGET -k -u 'https://localhost:9200/_cluster/health?pretty=true' Hier ein noch ausführlicherer Befehl curl -XGET -k -u 'https://localhost:9200/_nodes?os=true&process=true&pretty=true' ==== Balancing ==== Zum Ein- und Ausschalten von Shard-Balancing (z.B. für Wartungen an einem Node) folgender Befehl curl -XPUT -k -u 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d'{"":{"cluster.routing.allocation.enable": }}' ^ all | (default) Allows shard allocation for all kinds of shards. | ^ primaries | Allows shard allocation only for primary shards. | ^ new_primaries | Allows shard allocation only for primary shards for new indices. | ^ none | No shard allocations of any kind are allowed for any indices. | ==== Abfrage per Webbrowser ==== [[http://elasticsearch-host:port/index-name/index-type/_search?q=]] oder [[http://elasticsearch-host:9200///_search?q=&pretty]] oder über die o.g. **Plugins**. ==== Settings ==== Zum ausgeben von aktuellen Einstellungen des Elasticsearch-Clusters benutzt man folgenden Befehl. curl -XGET -k -u https://localhost:9200/_cluster/settings?pretty oder hier die Cluster-Einstellungen mit Default-Einstellungen curl -XGET -k -u 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 https://localhost:9200/_cluster/settings -H 'Content-Type: application/json' -d '{ "|" : { "" : "" } }' === Nodes ignorieren === Hier ein Beispiel um einen Node aus dem Cluster zu ignorieren curl -XPUT -k -u 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{ "transient" : { "cluster.routing.allocation.exclude._ip" : "10.0.0.1" } }' === Anzahl Nodes === Um die Anzahl an Master-Nodes zu ändern folgender Befehl **persistent** curl -XPUT -k -u 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{ "persistent" : { "discovery.zen.minimum_master_nodes" : 2 } }' **transient** curl -XPUT -k -u 'https://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' -d '{ "transient" : { "discovery.zen.minimum_master_nodes" : 2 } }' === Discovery === Um das ZEN Discovery auszuschalten, nutzt man folgenden Befehl curl -XPUT -k -u 'https://localhost:9200/_cluster/settings?pretty=true' -H 'Content-Type: application/json' -d '{transient: {"discovery.zen.ping.multicast.ping.enabled": false}}' ==== Refresh Index ==== curl -XPOST -k -u https://localhost:9200/[*]/_refresh ==== Close Index ==== curl -XPOST -k -u https://localhost:9200/[*]/_close ==== Delete Index ==== curl -XDELETE -k -u https://localhost:9200/[*] ===== Backup ===== ==== bis ES 1.5 ==== Quelle: [[https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html|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. === Repository erstellen === 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 === Snapshot === 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. === Backup Script === #!/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 === Restore === 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. === Monitoring Snapshot oder Restore === 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 ==== bis ES 0.90.x ==== Die Datensicherung erfolgt bei einem [[http://www.elasticsearch.org/guide/reference/modules/gateway/local/|local Gateway]] und z.B. einem [[http://www.elasticsearch.org/guide/reference/glossary/|node]] in folgenden Schritten: - Erstes (und einziges) Full-Backup per ''rsync'' (Da die ES noch läuft und weiter Fleissig Indices schreibt ist das eine inkonsistente Datensicherung) - nun stoppt man das "refreshing" der Datenbank in die Indices - nach dem Stoppen refresht man nun einen letzten Stand - jetzt kann wieder mit ''rsync'' eine Datensicherung gemacht werden (Nun inkrementell und konsistent) - nach der DaSi startet mann wieder dass "refreshing" ==== Script ==== #!/bin/bash # Datensicherungsziel OHNE abschliessenden Slash DEST="" SRC="" #### 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 ===== 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 ===== Upgradeverfahren ===== * Elasticsearch curl -k -u -X PUT "https://localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d' { "persistent": { "cluster.routing.allocation.enable": "primaries" } } ' curl -k -u -X POST "https://localhost:9200/_flush/synced?pretty" systemctl stop elasticsearch.service dpkg -i ...deb systemctl start elasticsearch.service curl -k -u -X GET "https://localhost:9200/_cat/nodes?pretty" curl -k -u -X PUT "https://localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d' { "persistent": { "cluster.routing.allocation.enable": null } } ' curl -k -u -X GET "https://localhost:9200/_cat/health?v&pretty" ===== Troubleshooting ===== ==== to many files open ==== vi /etc/elasticsearch/elasticsearch.yml Hier folgenden Parameter prüfen (Standardwert ist: 65535) MAX_OPEN_FILES Quelle: [[http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-service.html|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: [[http://www.elasticsearch.org/tutorials/too-many-open-files/|Elasticsearch-Tutuorials]] ==== Unassigned Shards ==== 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 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 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 'https://http://localhost:9200/_cluster/reroute?pretty=true' -H 'Content-Type: application/json' -d '{ "commands" : [ { "allocate" : { "index" : "", "shard" : '$i' , "node" : "", "allow_primary" : <0|1> }}]}'; done Rerouting von Shards mit der Einstellung ''index.routing.allocation.enable'': ^ Wert ^ Beschreibung ^ | all (default) | alle Shards | | primaries | shard allocation nur für primary shards | | new_primaries | shard allocation nur für neu erstellte primary shards | | none | keine shard allocation | * auf einen bestimmten Index curl -XPUT -k -u 'https://localhost:9200//_settings' -H 'Content-Type: application/json' -d ' {"index.routing.allocation.enable": "none"}' * oder auf einen Node curl -XPUT -k -u 'https://localhost:9200/_settings' -H 'Content-Type: application/json' -d ' {"index.routing.allocation.enable": "none"}' === Script === 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 'https://localhost:9200/_cluster/state/nodes?pretty'|grep -B1 name read -p "Internal_Node_ID:" NODE #NODE="" #read -p "Elasicsearch Index:" INDEX INDEX=`curl -XGET -k -u 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 'https://localhost:9200/_cluster/reroute' -H 'Content-Type: application/json' -d '{"commands":[{"allocate":{"node":"'${NODE}'", "allow_primary": true, "index":"'${line}'", "shard":'$i'}}]}' done done ==== Replikate ==== 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 'https://localhost:9200//_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 'https://localhost:9200/_settings' -H 'Content-Type: application/json' -d '{"index.number_of_replicas":0}' ==== Zugriff ab Version 1.4 ==== 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://.. #http.cors.allow-origin: /https?:\/\/(.*)?\.(:[0-9]{1,5})?(/.*)? Mit dem Parameter ''http.cors.allow-origin'' kann der zugriff von bestimmten URLs erlaubt/verweigert werden. Siehe dazu die [[http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-http.html|Doku]] von Elasticsearch.