Saúde do cluster Elasticsearch(ES): análise de falha vermelha

Pequeno · Postado em 2021-1-27 23:08:07

Usando o painel de cabeça elasticsearch para conectar ao Elasticsearch(ES), encontrei o seguinte erro:

Vida do Cluster: vermelho (24 de 31)

Para ver informações de status, visite:O login do hiperlink está visível.

{
  "cluster_name" : "elasticsearch",
  "status" : "vermelho",
  "timed_out" : falso,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 24,
  "active_shards" : 24,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 7,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 77.41935483870968
}

"status": "vermelho"O status é Vazio

O plugin da cabeça será exibido em cores diferentes

1) Verde - o estado mais saudável, o que significa que todos os fragmentos primários e réplicas estão disponíveis;
2) Amarelo - todos os fragmentos primários estão disponíveis, mas alguns fragmentos réplica não estão disponíveis;
3) Vermelho - Alguns fragmentos primários não estão disponíveis. (Neste momento, alguns dados ainda podem ser encontrados ao executar a consulta, então é melhor resolvê-la rapidamente.) ）

Para ver o status do índice, acesse:O login do hiperlink está visível.

.monitoramento-es-6-2021.01.22 0 p NÃO ATRIBUÍDO ALLOCATION_FAILED

O que é fragmentação não atribuída?

Explicação em uma frase: fragmentos não alocados.
Ao iniciar o ES, você verá que os fragmentos do cluster aparecem roxos, cinza e finalmente verdes após atualizarem constantemente pelo plug-in Head.

Por que ocorre fragmentação não atribuída?

Se você não puder alocar shards, por exemplo, se tiver superalocado o número de shards réplica para o número de nós no cluster, os shards permanecem NÃO AATRIBUÍDOS.
O código de erro é: ALLOCATION_FAILED.

Possíveis causas de problemas de fragmentação não atribuída?

1) INDEX_CREATED: Não alocado devido à API que criou o índice.
2) CLUSTER_RECOVERED: Não alocado devido à recuperação completa do cluster.
3) INDEX_REOPENED: Não alocado devido à abertura de um índice ou fechamento.
4) DANGLING_INDEX_IMPORTED: Não alocado devido ao resultado da importação do índice pendente.
5) NEW_INDEX_RESTORED: Não alocado devido ao retorno para um novo índice.
6) EXISTING_INDEX_RESTORED: Não alocado devido ao retorno para um índice fechado.
7) REPLICA_ADDED: Não alocado devido à adição explícita de fragmentos réplica.
8) ALLOCATION_FAILED: Não alocado devido a falha na alocação de fragmentos.
9) NODE_LEFT: O nó que carrega o fragmento sai do cluster e não é alocado.
10) REINICIALIZADO: Devido a fragmentos não alocados ao passar do início para a inicialização (por exemplo, fragmentação com cópias sombra de sombra).
11) REROUTE_CANCELLED: Desalocar como resultado de um comando explícito de desamarrar a remarinha.
12) REALLOCATED_REPLICA: Determinar que uma localização melhor para réplica está calibrada para uso, resultando no cancelamento da alocação e desalocação de cópias existentes.

Faça login no servidor e visualize os logs do Elasticsearch (ES) da seguinte forma:

Elasticsearch gera muitos logs, todos no diretório ES_HOME/logs. O nível padrão de registro é INFO. Ele fornece informações moderadas, mas é projetado para não sobrecarregar seus registros.

O login do hiperlink está visível.

Há um grande número de erros, tais como:

[2021-01-21T03:33:26,435] [AVISO] [o.e.x.m.e.l.LocalExporter] [A_OefhJ] erro inesperado ao indexar o documento de monitoramento
org.elasticsearch.xpack.monitoring.exporter.ExportException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
em org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.lambda$throwExportException$2(LocalBulk.java:128) ~[?:?]
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_222]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:1.8.0_222]
at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) ~[?:1.8.0_222]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) ~[?:1.8.0_222]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) ~[?:1.8.0_222]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:1.8.0_222]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:1.8.0_222]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_222]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485) ~[?:1.8.0_222]
em org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.throwExportException(LocalBulk.java:129) ~[?:?]
em org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.lambda$doFlush$0(LocalBulk.java:111) ~[?:?]
em org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.ContextPreservingActionListener.onResponse(ContextPreservingActionListener.java:43) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:85) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:81) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction$BulkRequestModifier.lambda$wrapActionActionListenerIfNeeded$0(TransportBulkAction.java:607) ~[elasticsearch-6.5.2.jar :6.5.2]
em org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.finishHim(TransportBulkAction.java:414) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.onFailure(TransportBulkAction.java:409) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.TransportAction$1.onFailure(TransportAction.java:91) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.finishAsFailed(TransportReplicationAction.java:901) ~[elasticsearch-6.5.2.jar :6.5.2]
em org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockException(TransportReplicationAction.java:824) ~[ elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockExceptions(TransportReplicationAction.java:812) ~[ elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.doRun(TransportReplicationAction.java:710) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.replication.TransportReplicationAction.doExecute(TransportReplicationAction.java:169) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.replication.TransportReplicationAction.doExecute(TransportReplicationAction.java:97) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:167) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.xpack.security.action.filter.SecurityActionFilter.apply(SecurityActionFilter.java:126) ~[?:?]
em org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:165) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:139) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:81) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation.doRun(TransportBulkAction.java:384) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction.executeBulk(TransportBulkAction.java:496) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction.executeIngestAndBulk(TransportBulkAction.java:243) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction.doExecute(TransportBulkAction.java:169) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.bulk.TransportBulkAction.lambda$processBulkIndexIngestRequest$4(TransportBulkAction.java:549) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.ingest.IngestService$4.doRun(IngestService.java:417) [elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:723) [elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-6.5.2.jar:6.5.2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
em java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Causado por: org.elasticsearch.cluster.block.ClusterBlockException: bloqueado por: [PROIBIDO/12/índice somente leitura / permitir exclusão (api)];
em org.elasticsearch.cluster.block.ClusterBlocks.indexBlockedException(ClusterBlocks.java:183) ~[elasticsearch-6.5.2.jar:6.5.2]
em org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockExceptions(TransportReplicationAction.java:810) ~[ elasticsearch-6.5.2.jar:6.5.2]
... Mais 21

Após análise, constatou-se que era porqueO espaço em disco do servidor onde o ES está localizado é muito baixo, uma vez que qualquer índice com um ou mais fragmentos seja atribuído a um nó em um disco que armazene mais de 95% dos dados, o índice será forçado a entrar no modo somente leitura.

O CentOS conta o tamanho de cada pasta e procura arquivos grandes
https://www.itsvse.com/thread-9542-1-1.html

Veja todas as informações de configurações de índice para visitar:O login do hiperlink está visível., como mostrado na figura abaixo:

"conhecimento" : {
"configurações" : {
   "index" : {
      "number_of_shards" : "3",
      "bloqueios" : {
      "read_only_allow_delete" : "Verdadeiro"
      },
      "provided_name" : "conhecimento",
      "creation_date" : "1576206251443",
      "number_of_replicas" : "0",
      "uuid": "yeSIP_otQo6JQ8ooRdr8hA",
      "versão" : {
      "criado": "6050299"
      }
   }
}
  }

read_only_allow_deleteQuando esse atributo é verdadeiro, o índice ES só permite ler e excluir dados, e não permite adicionar ou modificar dados

solução

Após resolver o problema do disco, expanda ou exclua arquivos indesejados, siga o tutorial abaixo.

Defina read_only_allow_delete como falso

O login está visível.

Envie uma requisição de put usando elasticsearch-head:O login do hiperlink está visível., como mostrado na figura abaixo:

O login está visível.

{
"reconhecido": verdade
}

Isso ainda não pode tirar o estado de saúde do Red,Exclua diretamente os dados ".monitoring-es-6-*", o estado se torna saudável, como mostrado na figura abaixo:

(Fim)

Pequeno · Postado em 2021-6-15 11:22:58

-- Ver todos os status dos índices

O login do hiperlink está visível.

-- Visualizar índices com status vermelho
O login do hiperlink está visível.

Documentação:O login do hiperlink está visível.

Pequeno · Postado em 17-04-2023 12:12:32

O Elasticsearch (ES) falha em gravar dados na solução de falha
https://www.itsvse.com/thread-10568-1-1.html

Saúde do cluster Elasticsearch(ES): análise de falha vermelha

Posts Relacionados

Seções visualizadas