Kibana: Kibana bleibt schreibgeschützt, wenn das ES-High-Disk-Wasserzeichen überschritten und später unter das Limit gefallen ist

Erstellt am 24. Aug. 2017  ·  22Kommentare  ·  Quelle: elastic/kibana

Kibana-Version : 6.0.0-beta1

Elasticsearch-Version : 6.0.0-beta1

Server - Version: Ubuntu 16.04.2 LTS

Browser -

Browser-Betriebssystemversion : Windows 10

Ursprüngliche Installationsmethode (z. B. Download-Seite, yum, aus der Quelle usw.) : Offizielle tar.gz-Pakete

Beschreibung des Problems einschließlich erwartetem und tatsächlichem Verhalten :

Ich betreibe eine Einzelknoten-Elasticsearch-Instanz, Logstash und Kibana. Alles läuft auf demselben Host in separaten Docker-Containern.

Wenn das High Disk Watermark auf dem ES-Host überschritten wird, wird Folgendes im Elasticsearch-Protokoll protokolliert:

[2017-08-24T07:45:11,757][INFO ][o.e.c.r.a.DiskThresholdMonitor] [CSOifAr] rerouting shards: [high disk watermark exceeded on one or more nodes]
[2017-08-24T07:45:41,760][WARN ][o.e.c.r.a.DiskThresholdMonitor] [CSOifAr] flood stage disk watermark [95%] exceeded on [CSOifArqQK-7PBZM_keNoA][CSOifAr][/data/elasticsearch/nodes/0] free: 693.8mb[2.1%], all indice
s on this node will marked read-only

Wenn dies passiert ist, werden Änderungen am .kibana Index natürlich fehlschlagen, da der Index nicht beschrieben werden kann. Dies kann beobachtet werden, indem versucht wird, eine beliebige Einstellung unter _Management_->_Erweiterte Einstellungen_ zu ändern, bei der eine Änderung von zB _ Config: Error 403 Forbidden: blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]; fehlschlägt

index_read_only

Wenn jetzt mehr Speicherplatz zur Verfügung gestellt wird, protokolliert ES, dass der Knoten unter das High Watermark gegangen ist:

[2017-08-24T07:47:11,774][INFO ][o.e.c.r.a.DiskThresholdMonitor] [CSOifAr] rerouting shards: [one or more nodes has gone under the high or low watermark]

Man würde nun annehmen, dass es möglich wäre, Änderungen an den Kibana-Einstellungen vorzunehmen, aber der Versuch, eine Einstellungsänderung vorzunehmen, schlägt immer noch mit der Fehlermeldung fehl:

Config: Error 403 Forbidden: blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];

Schritte zur Reproduktion :

  1. Stellen Sie sicher, dass Einstellungsänderungen fehlerfrei durchgeführt werden können
  2. Füllen Sie die Elasticsearch-Datenplatte so, dass das High-Disk-Wasserzeichen überschritten wird (ich habe fallocate -l9G largefile )
  3. Überprüfen Sie im ES-Protokoll, dass das High Disk Watermark überschritten wurde und die Indizes als schreibgeschützt markiert wurden
  4. Führen Sie eine Einstellungsänderung durch und vergewissern Sie sich, dass sie fehlschlägt, da Schreibvorgänge verboten sind
  5. Beheben Sie die Bedingung für das hohe Festplatten-Wasserzeichen (was ich mit rm largefile getan habe)
  6. Stellen Sie sicher, dass im ES-Protokoll angegeben ist, dass der Knoten unter das High-Disk-Wasserzeichen gegangen ist (und daher geschrieben werden kann?)
  7. Führen Sie eine Einstellungsänderung durch und sie schlägt fehl, wenn sie tatsächlich erfolgreich sein sollte.
Pioneer Program Operations

Hilfreichster Kommentar

Ich bin gerade davon erwischt worden. Es ist nicht nur Kibana, alle Indizes werden gesperrt, wenn der Festplattenschwellenwert erreicht wird, und werden nie entsperrt, wenn Speicherplatz freigegeben wird.

So entsperren Sie alle Indizes manuell:

curl -XPUT -H "Content-Type: application/json" https://[YOUR_ELASTICSEARCH_ENDPOINT]:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Alle 22 Kommentare

Also, wie erhole ich mich davon? .kibana bleibt schreibgeschützt, egal was ich tue. Ich habe versucht, einen Snapshot zu erstellen, ihn zu löschen und aus dem Snapshot wiederherzustellen - immer noch schreibgeschützt ...

Ich bin gerade auf einer Testmaschine darauf gestoßen. Ich kann mein Leben lang nicht weiter Daten in den Cluster eingeben. Ich musste schließlich alle beteiligten Indizes wegblasen.

Ich habe das Problem gelöst, indem ich den .kibana-Index gelöscht habe:
/.kibana/ löschen
Ich verliere bestimmte Konfigurationen/Visualisierungen/Dashboards, aber es wurde entsperrt.

Ich bin gerade davon erwischt worden. Es ist nicht nur Kibana, alle Indizes werden gesperrt, wenn der Festplattenschwellenwert erreicht wird, und werden nie entsperrt, wenn Speicherplatz freigegeben wird.

So entsperren Sie alle Indizes manuell:

curl -XPUT -H "Content-Type: application/json" https://[YOUR_ELASTICSEARCH_ENDPOINT]:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Danke @xose , ich wurde gerade wieder davon getroffen und konnte mich mit dem von Ihnen vorgeschlagenen Befehl wiederherstellen :)

Das Problem trat bei allen Indizes auf, nicht nur bei .kibana .

Laut den ES-Protokollen wurden die Indizes aufgrund des geringen Speicherplatzes auf dem Elasticsearch-Host auf schreibgeschützt gesetzt. Ich betreibe einen einzelnen Host mit Elasticsearch, Kibana, Logstash dockerized zusammen mit einigen anderen Tools. Da dieses Problem andere Indizes betrifft, ist dies eher ein Elasticsearch-Problem und das in Kibana aufgetretene Problem ein Symptom für ein anderes Problem.

Dieser Fehler ist dumm. Kannst du es jetzt auflösen? Zumindest sollten Sie eine Warnung anzeigen und eine mögliche Lösung auflisten. Es ist wirklich dumm für mich, in das js-Fehlerprotokoll zu schauen und diesen Thread zu finden!

@saberkun Sie können es aufheben, indem Sie dem von @xose geposteten Befehl

curl -XPUT -H "Content-Type: application/json" https://[YOUR_ELASTICSEARCH_ENDPOINT]:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Ja, habe ich.

Am So, 26. November 2017 um 23:12 Aaron C. de Bruyn [email protected]
schrieb:

@saberkun https://github.com/saberkun Sie können es aufheben, indem Sie folgen
der Befehl @xose https://github.com/xose gepostet:

curl -XPUT -H "Content-Type: application/json" https://[YOUR_ELASTICSEARCH_ENDPOINT]:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/elastic/kibana/issues/13685#issuecomment-347074533 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEpb5RJrhqJ8fK9wxGtNvTZtomMtlqzZks5s6jbBgaJpZM4PBHOW
.

Können Sie zusätzliche Informationen bereitstellen? Haben Sie beim Ausführen des Befehls eine Fehlermeldung erhalten? Haben sich die Indizes entsperrt und jetzt kommt eine neue Fehlermeldung? Welche Fehlermeldungen sehen Sie jetzt in Ihren Protokolldateien?

Vielen Dank. Es wird durch den Befehl behoben. Ich meine ja, ich habe es verwendet, um das zu reparieren
Problem

Am So, 26. November 2017 um 23:19 Uhr Aaron C. de Bruyn [email protected]
schrieb:

Können Sie zusätzliche Informationen bereitstellen? Haben Sie eine Fehlermeldung erhalten, wenn
den Befehl ausführen? Haben die Indizes freigeschaltet und jetzt bekommst du eine neue
Fehlermeldung? Welche Fehlermeldungen sehen Sie jetzt in Ihren Protokolldateien?


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/elastic/kibana/issues/13685#issuecomment-347075205 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEpb5Xn5uJBlzvAyXkAjRPom-OiwJ43Gks5s6jg0gaJpZM4PBHOW
.

+1
Erhalten dieses Fehlers nach dem Upgrade von 5.5 auf 6.0

+1

ELK 6, halbes Laufwerk gelöscht noch schreibgeschützt, Logstash darf wieder schreiben, Kibana blieb schreibgeschützt

Es ist gelungen , das Problem mit der von Problemumgehung zu lösen

+1, gleicher Fehler bei mir.

Gleiches Problem bei mir. Wurde durch die Lösung von @xose gelöst.

Hier gilt das gleiche. Alle grüßen @xose.

Ich habe gerade einen Single-Node-Cluster von 6.0.0 auf 6.1.1 aktualisiert (sowohl ES als auch Kibana). Als ich die Dienste wieder startete, warf Kibana:

blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];

Wie beim letzten Mal musste ich den .kibana Index löschen, um ihn wieder zum Laufen zu bringen. Es gab auch den aktuellen Logstash-Index, bei dem einer der Shards als nicht zugeordnet aufgeführt war. Ich habe es auch gelöscht und dann die übliche Flut von Warnungen erhalten.

Mir ging der Speicherplatz nicht aus - auf diesem Testcomputer sind ~ 92 GB von 120 GB frei. Der Speicherort ist ZFS und ein Scrubbing hat keine Datenbeschädigungen ergeben.

Die einzigen Fehler im Log scheinen irrelevant zu sein:

[2018-01-13T20:48:14,579][INFO ][o.e.n.Node               ] [ripley1] stopping ...
[2018-01-13T20:48:14,597][ERROR][i.n.u.c.D.rejectedExecution] Failed to submit a listener notification task. Event loop shut down?
java.util.concurrent.RejectedExecutionException: event executor terminated
        at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:821) ~[netty-common-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:327) ~[netty-common-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:320) ~[netty-common-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:746) ~[netty-common-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.util.concurrent.DefaultPromise.safeExecute(DefaultPromise.java:760) [netty-common-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:428) [netty-common-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.util.concurrent.DefaultPromise.setFailure(DefaultPromise.java:113) [netty-common-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.channel.DefaultChannelPromise.setFailure(DefaultChannelPromise.java:87) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.channel.AbstractChannelHandlerContext.safeExecute(AbstractChannelHandlerContext.java:1010) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:825) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:794) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1027) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
        at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:301) [netty-transport-4.1.13.Final.jar:4.1.13.Final]
        at org.elasticsearch.http.netty4.Netty4HttpChannel.sendResponse(Netty4HttpChannel.java:146) [transport-netty4-6.0.0.jar:6.0.0]
        at org.elasticsearch.rest.RestController$ResourceHandlingHttpChannel.sendResponse(RestController.java:491) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.rest.action.RestResponseListener.processResponse(RestResponseListener.java:37) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.rest.action.RestActionListener.onResponse(RestActionListener.java:47) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:85) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:81) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.finishHim(TransportBulkAction.java:380) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.onFailure(TransportBulkAction.java:375) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.action.support.TransportAction$1.onFailure(TransportAction.java:91) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.finishAsFailed(TransportReplicationAction.java:908) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase$2.onClusterServiceClose(TransportReplicationAction.java:891) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.cluster.ClusterStateObserver$ContextPreservingListener.onClusterServiceClose(ClusterStateObserver.java:310) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onClose(ClusterStateObserver.java:230) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.cluster.service.ClusterApplierService.doStop(ClusterApplierService.java:168) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.common.component.AbstractLifecycleComponent.stop(AbstractLifecycleComponent.java:85) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.cluster.service.ClusterService.doStop(ClusterService.java:106) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.common.component.AbstractLifecycleComponent.stop(AbstractLifecycleComponent.java:85) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.node.Node.stop(Node.java:713) [elasticsearch-6.0.0.jar:6.0.0]
        at org.elasticsearch.node.Node.close(Node.java:735) [elasticsearch-6.0.0.jar:6.0.0]
        at org.apache.lucene.util.IOUtils.close(IOUtils.java:89) [lucene-core-7.0.1.jar:7.0.1 8d6c3889aa543954424d8ac1dbb3f03bf207140b - sarowe - 2017-10-02 14:36:35]
        at org.apache.lucene.util.IOUtils.close(IOUtils.java:76) [lucene-core-7.0.1.jar:7.0.1 8d6c3889aa543954424d8ac1dbb3f03bf207140b - sarowe - 2017-10-02 14:36:35]
        at org.elasticsearch.bootstrap.Bootstrap$4.run(Bootstrap.java:185) [elasticsearch-6.0.0.jar:6.0.0]
[2018-01-13T20:48:14,692][INFO ][o.e.n.Node               ] [ripley1] stopped
[2018-01-13T20:48:14,692][INFO ][o.e.n.Node               ] [ripley1] closing ...
[2018-01-13T20:48:14,704][INFO ][o.e.n.Node               ] [ripley1] closed
[2018-01-13T20:48:39,879][INFO ][o.e.n.Node               ] [ripley1] initializing ...
[2018-01-13T20:48:40,054][INFO ][o.e.e.NodeEnvironment    ] [ripley1] using [1] data paths, mounts [[/scratch/elasticsearch (scratch/elasticsearch)]], net usable_space [92.5gb], net total_space [93.6gb], types [zfs]
[2018-01-13T20:48:40,055][INFO ][o.e.e.NodeEnvironment    ] [ripley1] heap size [989.8mb], compressed ordinary object pointers [true]
[2018-01-13T20:48:40,119][INFO ][o.e.n.Node               ] [ripley1] node name [ripley1], node ID [TvkaGbQpR5KZ-ZScMZN6AQ]
[2018-01-13T20:48:40,119][INFO ][o.e.n.Node               ] [ripley1] version[6.1.1], pid[6942], build[bd92e7f/2017-12-17T20:23:25.338Z], OS[Linux/4.10.0-38-generic/amd64], JVM[Oracle Corporation/OpenJDK 64-Bit Server VM/1.8.0_151/25.151-b12]
[2018-01-13T20:48:40,120][INFO ][o.e.n.Node               ] [ripley1] JVM arguments [-Xms1g, -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=/var/lib/elasticsearch, -Des.path.home=/usr/share/elasticsearch, -Des.path.conf=/etc/elasticsearch]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [aggs-matrix-stats]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [analysis-common]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [ingest-common]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [lang-expression]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [lang-mustache]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [lang-painless]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [mapper-extras]
[2018-01-13T20:48:41,315][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [parent-join]
[2018-01-13T20:48:41,320][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [percolator]
[2018-01-13T20:48:41,320][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [reindex]
[2018-01-13T20:48:41,320][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [repository-url]
[2018-01-13T20:48:41,320][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [transport-netty4]
[2018-01-13T20:48:41,320][INFO ][o.e.p.PluginsService     ] [ripley1] loaded module [tribe]
[2018-01-13T20:48:41,321][INFO ][o.e.p.PluginsService     ] [ripley1] no plugins loaded
[2018-01-13T20:48:43,801][INFO ][o.e.d.DiscoveryModule    ] [ripley1] using discovery type [zen]
[2018-01-13T20:48:44,587][INFO ][o.e.n.Node               ] [ripley1] initialized
[2018-01-13T20:48:44,587][INFO ][o.e.n.Node               ] [ripley1] starting ...
[2018-01-13T20:48:44,587][INFO ][o.e.n.Node               ] [ripley1] starting ...
[2018-01-13T20:48:44,759][INFO ][o.e.t.TransportService   ] [ripley1] publish_address {192.168.42.40:9300}, bound_addresses {[::]:9300}
[2018-01-13T20:48:44,792][INFO ][o.e.b.BootstrapChecks    ] [ripley1] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks
[2018-01-13T20:48:47,864][INFO ][o.e.c.s.MasterService    ] [ripley1] zen-disco-elected-as-master ([0] nodes joined), reason: new_master {ripley1}{TvkaGbQpR5KZ-ZScMZN6AQ}{H39AkwwqS_i-fg3Gl5J8QQ}{192.168.42.40}{192.168.42.40:9300}
[2018-01-13T20:48:47,869][INFO ][o.e.c.s.ClusterApplierService] [ripley1] new_master {ripley1}{TvkaGbQpR5KZ-ZScMZN6AQ}{H39AkwwqS_i-fg3Gl5J8QQ}{192.168.42.40}{192.168.42.40:9300}, reason: apply cluster state (from master [master {ripley1}{TvkaGbQpR5KZ-ZScMZN6AQ}{H39AkwwqS_i-fg3Gl5J8QQ}{192.168.42.40}{192.168.42.40:9300} committed version [1] source [zen-disco-elected-as-master ([0] nodes joined)]])
[2018-01-13T20:48:47,884][INFO ][o.e.h.n.Netty4HttpServerTransport] [ripley1] publish_address {192.168.42.40:9200}, bound_addresses {[::]:9200}
[2018-01-13T20:48:47,884][INFO ][o.e.n.Node               ] [ripley1] started
[2018-01-13T20:48:48,326][INFO ][o.e.g.GatewayService     ] [ripley1] recovered [6] indices into cluster_state
[2018-01-13T20:49:01,493][INFO ][o.e.c.m.MetaDataDeleteIndexService] [ripley1] [logstash-2018.01.14/D0f_lDkSQpebPFcey6NHFw] deleting index
[2018-01-13T20:49:18,793][INFO ][o.e.c.m.MetaDataCreateIndexService] [ripley1] [logstash-2018.01.14] creating index, cause [auto(bulk api)], templates [logstash-*], shards [5]/[0], mappings []
[2018-01-13T20:49:18,937][INFO ][o.e.c.r.a.AllocationService] [ripley1] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[logstash-2018.01.14][4]] ...]).

+1 gleicher Fehler in 6.1.2

Dies ist eine Funktion von Elasticsearch. Laut Elasticsearch-Fehler all indices on this node will marked read-only .

Um dies für einen Index rückgängig zu machen, können Sie index.blocks.read_only_allow_delete auf null setzen.

Weitere Informationen hierzu finden Sie hier: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html

Zu Ihrer Information – für alle, die immer noch darauf stoßen, hier ein kurzer Einzeiler, um die Indizes zu korrigieren:
curl -s -H "Content-Type: application/json" http://localhost:9200/_cat/indices | awk '{ print $3 }' | sort | xargs -L 1 -I{} curl -s -XPUT -H "Content-Type: application/json" http://localhost:9200/{}/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Es greift eine Liste aller Indizes in Ihrem Cluster und sendet dann für jeden den Befehl, um ihn nicht schreibgeschützt zu machen.

Zu Ihrer Information – für alle, die immer noch darauf stoßen, hier ein kurzer Einzeiler, um die Indizes zu korrigieren:
curl -s -H "Content-Type: application/json" http://localhost:9200/_cat/indices | awk '{ print $3 }' | sort | xargs -L 1 -I{} curl -s -XPUT -H "Content-Type: application/json" http://localhost:9200/{}/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Es greift eine Liste aller Indizes in Ihrem Cluster und sendet dann für jeden den Befehl, um ihn nicht schreibgeschützt zu machen.

Ich habe dies auch getan, bis ich die Lösung von @darkpixel gefunden

Sie können diese Einstellung für _all vornehmen, anstatt nacheinander vorzugehen. In meinem Fall dauert es für Hunderte von Indizes ziemlich lange, während das Einstellen auf 'all' nur wenige Sekunden dauert.

curl -XPUT -H "Content-Type: application/json" https://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Ich habe das Problem gelöst, indem ich den .kibana-Index gelöscht habe:
/.kibana/ löschen
Ich verliere bestimmte Konfigurationen/Visualisierungen/Dashboards, aber es wurde entsperrt.

Vielen Dank für diese WA. Bei mir ist das Problem gelöst.

Das hat bei mir funktioniert. Beide Befehle wurden benötigt, um Kabana nach einer Neuinstallation zum Laufen zu bringen:

curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_cluster/settings -d '{ "transient": { "cluster.routing.allocation.disk.threshold_enabled": false } }'
curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

Dazu musste der .kibana-Index nicht gelöscht werden. Funktioniert jetzt einwandfrei!

Quelle:
https://selleo.com/til/posts/esrgfyxjee-how-to-fix-elasticsearch-forbidden12index-read-only

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen