Kibana: Kibana permanece en lectura solo cuando se ha superado la marca de agua de disco alta de ES y luego se ha ido por debajo del límite

Creado en 24 ago. 2017  ·  22Comentarios  ·  Fuente: elastic/kibana

Versión de Kibana : 6.0.0-beta1

Versión de Elasticsearch: 6.0.0-beta1

Versión del SO del servidor : Ubuntu 16.04.2 LTS

Versión del navegador : Chrome 60.0.3112.90

Versión del SO del navegador : Windows 10

Método de instalación original (por ejemplo, página de descarga, yum, desde la fuente, etc.) : paquetes oficiales de tar.gz

Descripción del problema, incluido el comportamiento esperado frente al real :

Estoy ejecutando una instancia de Elasticsearch de un solo nodo, logstash y Kibana. Todo se ejecuta en el mismo host en contenedores Docker separados.

Si se supera la marca de agua de disco alta en el host ES, se registra lo siguiente en el registro de elasticsearch:

[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

Cuando esto ha ocurrido, los cambios en el índice .kibana fallarán, por supuesto, ya que no se puede escribir en el índice. Esto se puede observar al intentar cambiar cualquier configuración en _Gestión _-> _ Configuración avanzada_ donde un cambio a, por ejemplo, _ búsqueda: idioma de consulta_ falla con el mensaje Config: Error 403 Forbidden: blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];

index_read_only

Si ahora hay más espacio en disco disponible, ES registrará que el nodo ha pasado por debajo de la marca de agua máxima:

[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]

Ahora se supondría que sería posible realizar cambios en la configuración de Kibana, pero intentar realizar un cambio de configuración aún falla con el mensaje de error:

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

Pasos para reproducir :

  1. Asegúrese de que los cambios de configuración se puedan realizar sin errores
  2. Llene el disco de datos de elasticsearch para que se exceda la marca de agua del disco alta (usé fallocate -l9G largefile )
  3. Verifique en el registro ES que se haya excedido la marca de agua del disco alta y que los índices se hayan marcado como de solo lectura
  4. Realice un cambio de configuración y verifique que falle, ya que las escrituras están prohibidas
  5. Resuelva la condición de marca de agua de disco alta (que hice con rm largefile )
  6. Verifique que el registro ES indique que el nodo ha pasado por debajo de la marca de agua del disco alta (y, por lo tanto, ¿debería ser posible escribir en él?)
  7. Realice un cambio de configuración y fallará cuando en realidad debería tener éxito.
Pioneer Program Operations

Comentario más útil

Me acaba de golpear esto. No es solo Kibana, todos los índices se bloquean cuando se alcanza el umbral del disco y nunca se desbloquean cuando se libera espacio.

Para desbloquear todos los índices manualmente:

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

Todos 22 comentarios

Entonces, ¿cómo me recupero de esto? .kibana permanece en lectura sin importar lo que haga. He intentado tomar una instantánea, eliminarlo y recuperarlo de la instantánea, todavía es de solo lectura ...

Me encontré con esto en una máquina de prueba. Por mi vida, no puedo seguir colocando datos en el clúster. Finalmente tuve que eliminar todos los índices involucrados.

Resolví el problema eliminando el índice .kibana:
eliminar /.kibana/
Pierdo ciertas configuraciones / visualizaciones / cuadros de mando pero se desbloqueó.

Me acaba de golpear esto. No es solo Kibana, todos los índices se bloquean cuando se alcanza el umbral del disco y nunca se desbloquean cuando se libera espacio.

Para desbloquear todos los índices manualmente:

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

Gracias @xose , esto me golpeó nuevamente y pude recuperarme usando el comando que sugirió :)

El problema ocurrió en todos los índices, no solo en el .kibana uno.

Según los registros de ES, los índices se establecieron en solo lectura debido al poco espacio en disco en el host de elasticsearch. Ejecuto un solo host con Elasticsearch, Kibana, Logstash acoplado junto con algunas otras herramientas. Dado que este problema afecta a otros índices, creo que se trata más de un problema de Elasticsearch y que el problema visto en Kibana es un síntoma de otro problema.

Este error es estúpido. ¿Puedes deshacerlo por ahora? Al menos debería mostrar una advertencia y enumerar una posible solución. ¡Es realmente estúpido de mi parte buscar en el registro de errores de js y encontrar este hilo!

@saberkun Puede deshacerlo siguiendo el comando @xose publicado:

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

Sí, lo hice.

El domingo 26 de noviembre de 2017 a las 11:12 p.m. Aaron C. de Bruyn [email protected]
escribió:

@saberkun https://github.com/saberkun Puede deshacerlo siguiendo
el comando @xose https://github.com/xose publicado:

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

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/elastic/kibana/issues/13685#issuecomment-347074533 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEpb5RJrhqJ8fK9wxGtNvTZtomMtlqzZks5s6jbBgaJpZM4PBHOW
.

¿Puede proporcionar información adicional? ¿Recibió un error al ejecutar el comando? ¿Se desbloquearon los índices y ahora aparece un nuevo mensaje de error? ¿Qué mensajes de error está viendo ahora en sus archivos de registro?

Gracias. Lo fija el comando. Quiero decir, sí, lo usé para arreglar el
problema

El domingo, 26 de noviembre de 2017 a las 11:19 p.m. Aaron C. de Bruyn [email protected]
escribió:

¿Puede proporcionar información adicional? Recibiste un error cuando
ejecutando el comando? ¿Se desbloquearon los índices y ahora está obteniendo un nuevo
¿mensaje de error? ¿Qué mensajes de error está viendo ahora en sus archivos de registro?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/elastic/kibana/issues/13685#issuecomment-347075205 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEpb5Xn5uJBlzvAyXkAjRPom-OiwJ43Gks5s6jg0gaJpZM4PBHOW
.

+1
Recibiendo este error después de la actualización de 5.5 a 6.0

+1

ELK 6, borrado la mitad de la unidad sigue siendo de solo lectura, logstash puede escribir de nuevo, kibana sigue siendo de solo lectura

Gestionado para resolver el problema con la solución proporcionada por @xose

+1, el mismo error para mí.

El mismo problema para mí. Se resolvió mediante la solución dada por @xose.

Aquí igual. Todos saludan @xose.

Acabo de actualizar un clúster de un solo nodo de 6.0.0 a 6.1.1 (tanto ES como Kibana). Cuando comencé la copia de seguridad de los servicios, Kibana estaba lanzando:

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

Igual que la última vez: tuve que eliminar el índice .kibana para volver a funcionar. También estaba el índice logstash actual con uno de los fragmentos enumerados como no asignados. También lo eliminé y luego recibí la avalancha habitual de alertas.

No me quedé sin espacio: hay ~ 92 GB de 120 GB libres en esta máquina de prueba. La ubicación de almacenamiento es ZFS y una limpieza no reveló ningún daño en los datos.

Los únicos errores en el registro parecen ser irrelevantes:

[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 mismo error en 6.1.2

Esta es una función de Elasticsearch. Según el error de Elasticsearch, all indices on this node will marked read-only .

Para revertir esto para un índice, puede establecer index.blocks.read_only_allow_delete en nulo.

Puede encontrar más información sobre esto aquí: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html

Para su información, para cualquiera que todavía se encuentre con esto, aquí hay un resumen rápido para corregir los índices:
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}'

Toma una lista de todos los índices en su clúster, luego, para cada uno, envía el comando para que no sea de solo lectura.

Para su información, para cualquiera que todavía se encuentre con esto, aquí hay un resumen rápido para corregir los índices:
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}'

Toma una lista de todos los índices en su clúster, luego, para cada uno, envía el comando para que no sea de solo lectura.

Yo también estaba haciendo esto hasta que encontré la solución de @darkpixel (https://github.com/elastic/kibana/issues/13685#issuecomment-347074533)

Puede hacer esta configuración para _todos en lugar de hacerlo uno por uno. En mi caso, toma bastante tiempo hacerlo para cientos de índices, mientras que configurar en 'todos' toma solo unos segundos.

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

Resolví el problema eliminando el índice .kibana:
eliminar /.kibana/
Pierdo ciertas configuraciones / visualizaciones / cuadros de mando pero se desbloqueó.

Muchas gracias por este WA. Es un problema resuelto para mí.

Esto funcionó para mí. Ambos comandos eran necesarios para que kabana funcionara después de una nueva instalación:

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}'

Esto no requirió eliminar el índice .kibana. ¡Funciona perfectamente ahora!

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

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

timmolter picture timmolter  ·  3Comentarios

timroes picture timroes  ·  3Comentarios

snide picture snide  ·  3Comentarios

tbragin picture tbragin  ·  3Comentarios

LukeMathWalker picture LukeMathWalker  ·  3Comentarios