Здравето на клъстера в Elasticsearch(ES): червено Анализ на неуспехи

Малък боклук · Публикувано на 27.01.2021 23:08:07

Използвайки панела elasticsearch-head за свързване с Elasticsearch(ES), открих следната грешка:

Клъстерно здраве: червено (24 от 31)

За да видите информация за статуса, посетете:Входът към хиперлинк е видим.

{
  "cluster_name" : "elasticsearch",
  "статус" : "червен",
  "timed_out" : false,
  "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
}

"статус" : "червен"Статусът е Празно

Плъгинът за глава ще се показва в различни цветове

1) Зелено – най-здравословното състояние, което означава, че всички първични и реплики са налични;
2) Жълто – всички основни фрагменти са налични, но някои реплики не са налични;
3) Червено - Някои основни фрагменти не са налични. (В момента все още могат да се намерят някои данни при изпълнение на заявката, затова е по-добре да се реши бързо.) ）

За да видите статуса на индекса, достъпете:Входът към хиперлинк е видим.

.monitoring-es-6-2021.01.22 0 p НЕНАЗНАЧЕН ALLOCATION_FAILED

Какво е неопределено шардинг?

Обяснение в едно изречение: Неразпределени фрагменти.
Когато стартирате ES, ще забележите, че клъстерните фрагменти ще изглеждат лилави, сиви и накрая зелени след постоянно обновяване през плъгина на главата.

Защо се случва неопределено шардинг?

Ако не можете да разпределите шардове, например, ако сте прекалено разпределили броя на реплики шардове за броя на възлите в клъстера, шардовете остават НЕПРИСВОЕНИ.
Кодът за грешка е: ALLOCATION_FAILED.

Възможни причини за проблеми с неразпределеното шардинг?

1) INDEX_CREATED: Не е разпределен поради API-то, което е създало индекса.
2) CLUSTER_RECOVERED: Не е разпределен поради пълно възстановяване на клъстера.
3) INDEX_REOPENED: Не е разпределен поради отваряне или затваряне на индекс.
4) DANGLING_INDEX_IMPORTED: Не е разпределен поради резултата от внасянето на висящия индекс.
5) NEW_INDEX_RESTORED: Не е разпределен поради връщане към нов индекс.
6) EXISTING_INDEX_RESTORED: Не е разпределен поради връщане към затворен индекс.
7) REPLICA_ADDED: Не е разпределен поради изрично добавяне на фрагменти на реплики.
8) ALLOCATION_FAILED: Не е разпределен поради неуспешно разпределение на шард.
9) NODE_LEFT: Възелът, който носи шарда, напуска клъстера и не е разпределен.
10) РЕИНИЦИАЛИЗИРАНИ: Поради неразпределени шардове при преминаване от старт към инициализация (например шардиране с сенчести копия).
11) REROUTE_CANCELLED: Deallocate в резултат на явна команда за unresail.
12) REALLOCATED_REPLICA: Да се определи, че по-добро място на репликата е калибрирано за използване, което води до анулиране на съществуващото и неразпределението на копията.

Влезте в сървъра и прегледайте логовете на Elasticsearch (ES) по следния начин:

Elasticsearch генерира много логове, всички в директорията ES_HOME/logs. Стандартното ниво на логване е INFO. Тя предоставя умерена информация, но е създадена да не претоварва логовете ви.

Входът към хиперлинк е видим.

Има голям брой грешки като:

[2021-01-21T03:33:26,435] [ПРЕДУПРЕЖДЕНИЕ] [o.e.x.m.e.l.LocalExporter] [A_OefhJ] неочаквана грешка при индексиране на мониторинг на документа
org.elasticsearch.xpack.monitoring.exporter.ExportException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
на 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]
на org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.throwExportException(LocalBulk.java:129) ~[?:?]
на org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.lambda$doFlush$0(LocalBulk.java:111) ~[?:?]
на org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.ContextPreservingActionListener.onResponse(ContextPreservingActionListener.java:43) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:85) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:81) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.bulk.TransportBulkAction$BulkRequestModifier.lambda$wrapActionListenerIfNeeded$0(TransportBulkAction.java:607) ~[elasticsearch-6.5.2.jar :6.5.2]
на org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2]
в org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.finishHim(TransportBulkAction.java:414) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.onFailure(TransportBulkAction.java:409) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.TransportAction$1.onFailure(TransportAction.java:91) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.finishAsFailed(TransportReplicationAction.java:901) ~[elasticsearch-6.5.2.jar :6.5.2]
на org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockException(TransportReplicationAction.java:824) ~[ elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockExceptions(TransportReplicationAction.java:812) ~[ elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.doRun(TransportReplicationAction.java:710) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.replication.TransportReplicationAction.doExecute(TransportReplicationAction.java:169) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.replication.TransportReplicationAction.doExecute(TransportReplicationAction.java:97) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:167) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.xpack.security.action.filter.SecurityActionFilter.apply(SecurityActionFilter.java:126) ~[?:?]
на org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:165) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:139) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:81) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation.doRun(TransportBulkAction.java:384) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.bulk.TransportBulkAction.executeBulk(TransportBulkAction.java:496) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.bulk.TransportBulkAction.executeIngestAndBulk(TransportBulkAction.java:243) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.bulk.TransportBulkAction.doExecute(TransportBulkAction.java:169) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.bulk.TransportBulkAction.lambda$processBulkIndexIngestRequest$4(TransportBulkAction.java:549) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.ingest.IngestService$4.doRun(IngestService.java:417) [elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:723) [elasticsearch-6.5.2.jar:6.5.2]
на 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]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Причинено от: org.elasticsearch.cluster.block.ClusterBlockException: блокирано от: [ЗАБРАНЕН/12/index само за четене / allow delete (api)];
на org.elasticsearch.cluster.block.ClusterBlocks.indexBlockedException(ClusterBlocks.java:183) ~[elasticsearch-6.5.2.jar:6.5.2]
на org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockExceptions(TransportReplicationAction.java:810) ~[ elasticsearch-6.5.2.jar:6.5.2]
... Още 21

След анализ беше установено, че причината еДисковото пространство на сървъра, където се намира ES, е твърде малко, след като някой индекс с един или повече шарди бъде присвоен на възел в диск, който съхранява повече от 95% от данните, индексът ще бъде принуден да премине в режим само за четене.

CentOS брои размера на всяка папка и търси големи файлове
https://www.itsvse.com/thread-9542-1-1.html

Вижте цялата информация за настройките на индекса, за да посетите:Входът към хиперлинк е видим., както е показано на фигурата по-долу:

"знание" : {
"settings" : {
   "index" : {
      "number_of_shards" : "3",
      "блокове" : {
      "read_only_allow_delete" : "true"
      },
      "provided_name" : "знание",
      "creation_date" : "1576206251443",
      "number_of_replicas" : "0",
      "uuid" : "yeSIP_otQo6JQ8ooRdr8hA",
      "версия" : {
      "създаден" : "6050299"
      }
   }
}
  }

read_only_allow_deleteКогато този атрибут е верен, ES индексът позволява само четене и изтриване на данни и не позволява добавяне или промяна на данни

решение

След като решите проблема с диска, разширете или изтрийте нежелани файлове, следвайте урока по-долу.

Настрой read_only_allow_delete на false

Входът е видим.

Можете да изпратите заявка за put чрез elasticsearch-head:Входът към хиперлинк е видим., както е показано на фигурата по-долу:

Входът е видим.

{
"Потвърдено": вярно
}

Това все още не може да се отърве от здравословното състояние на Ред,Изтрийте данните ".monitoring-es-6-*" директно, състоянието става здравословно, както е показано на фигурата по-долу:

(Край)

Малък боклук · Публикувано на 2021-6-15 11:22:58

-- Преглед на всички индексни статуси

Входът към хиперлинк е видим.

-- Вижте индекси със статус червен
Входът към хиперлинк е видим.

Документация:Входът към хиперлинк е видим.

Малък боклук · Публикувано на 2023-4-17 12:32

Elasticsearch (ES) не успява да записва данни към решението за грешка
https://www.itsvse.com/thread-10568-1-1.html

Здравето на клъстера в Elasticsearch(ES): червено Анализ на неуспехи

Свързани публикации

Разгледани секции