|
|
Közzétéve: 2021-1-27 23:08:07
|
|
|
|
Az elasticsearch-fej panelrel az Elasticsearch(ES) csatlakozáshoz a következő hibát találtam:
Klaszter életerő: piros (24/31) 
Az állapotinformációk megtekintéséhez látogasson el a következő oldalra:A hiperlink bejelentkezés látható.
{
"cluster_name" : "rugalmas keresés",
"állapot": "piros",
"timed_out" : hamis,
"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
}
A fejplugin különböző színekben jelenik meg
1) Zöld – a legegészségesebb állapot, ami azt jelenti, hogy minden elsődleges és replika szilánk elérhető;
2) Sárga – minden elsődleges szilánk elérhető, de néhány replika szilánk nincs;
3) Piros – Néhány elsődleges shard-szelvény nem elérhető. (Jelenleg még néhány adat megtalálható a lekérdezés végrehajtása közben, ezért jobb gyorsan megoldani.) ）
Az index státuszának megtekintéséhez a következő hozzáférés:A hiperlink bejelentkezés látható.
.monitoring-es-6-2021.01.22 0p NEM KIOSZTOTT ALLOCATION_FAILED
Magyarázat egy mondatban: Szétszóratlan szilánkok.
Az ES-t indítva azt tapasztalhatod, hogy a klaszterdarabok lilának, szürkének, végül pedig zöldnek jelennek meg, miután folyamatosan frissíted a Head plug-in-en.
Miért fordul elő a nem kijelölt sharding?
Ha például nem tudsz shardokat kiosztani, akkor túlosztod a replika shardok számát a klaszterben lévő csomópontok számához képest, akkor a shardok NEM KIOSZTOTTAK maradnak.
A hibakód: ALLOCATION_FAILED.
Lehetséges okai a nem rendelt sharding problémákra?
1) INDEX_CREATED: Nem kiosztva az API miatt, amely létrehozta az indexet.
2) CLUSTER_RECOVERED: Nem osztották ki a teljes klaszterregeneráció miatt.
3) INDEX_REOPENED: Nem osztják ki az indexet nyitva vagy zárva.
4) DANGLING_INDEX_IMPORTED: Nem osztották ki a lógó index importjának eredménye miatt.
5) NEW_INDEX_RESTORED: Nem osztották ki, mivel visszatért egy új indexhez.
6) EXISTING_INDEX_RESTORED: Nem osztották le, mert visszakerült zárt indexre.
7) REPLICA_ADDED: Nem osztották ki, mert kifejezetten hozzáadták a replika töredékeket.
8) ALLOCATION_FAILED: Nem osztották ki a szilánkok allokációjának meghibásodása miatt.
9) NODE_LEFT: A töredéket szállító csomópont elhagyja a klasztert, és nem van kiosztva.
10) ÚJRAINICIALIZÁLT: A kezdésből inicializációba történő áthelyezéskor nem osztott szilánkok miatt (pl. árnyékárnyékmásolatokkal történő sharding).
11) REROUTE_CANCELLED: Leosztás egy explicit unresail parancs következtében.
12) REALLOCATED_REPLICA: Megállapítsuk, hogy egy jobb replika helyet kalibrálnak használatra, ami a meglévő példányok allokációjának és kivonásának törléséhez vezet.
Jelentkezzen be a szerverre, és tekintse meg az Elasticsearch (ES) naplókat az alábbiakban:
A Elasticsearch sok naplót ad ki, mind a ES_HOME/logs könyvtárban. Az alapértelmezett naplózási szint az INFO. Közepes információt ad, de úgy tervezték, hogy ne terhelje el a naplóidat.
Számos hiba létezik, például:
[2021-01-21T03:33:26,435] [FIGYELMEZTETÉS] [o.e.x.m.e.l.LocalExporter] [A_OefhJ] váratlan hiba a megfigyelő dokumentum indexálása közben
org.elasticsearch.xpack.monitoring.exporter.ExportException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
at 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]
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) ~[?:1.8.0_222] címen
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]
at org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.throwExportException(LocalBulk.java:129) ~[?:?]
at org.elasticsearch.xpack.monitoring.exporter.local.LocalBulk.lambda$doFlush$0(LocalBulk.java:111) ~[?:?]
a org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2] címen
a org.elasticsearch.action.support.ContextPreservingActionListener.onResponse(ContextPreservingActionListener.java:43) ~[elasticsearch-6.5.2.jar:6.5.2] címen
az org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:85) ~[elasticsearch-6.5.2.jar:6.5.2] címen
at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:81) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.bulk.TransportBulkAction$BulkRequestModifier.lambda$wrapActionListenerIfNeeded$0(TransportBulkAction.java:607) ~[elasticsearch-6.5.2.jar :6.5.2]
a org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2] címen
at org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.finishHim(TransportBulkAction.java:414) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.onFailure(TransportBulkAction.java:409) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.TransportAction$1.onFailure(TransportAction.java:91) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.finishAsFailed(TransportReplicationAction.java:901) ~[elasticsearch-6.5.2.jar :6.5.2]
at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockException(TransportReplicationAction.java:824) ~[ elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockExceptions(TransportReplicationAction.java:812) ~[ elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.doRun(TransportReplicationAction.java:710) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-6.5.2.jar:6.5.2] címen
at org.elasticsearch.action.support.replication.TransportReplicationAction.doExecute(TransportReplicationAction.java:169) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.replication.TransportReplicationAction.doExecute(TransportReplicationAction.java:97) ~[elasticsearch-6.5.2.jar:6.5.2]
at 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) ~[?:?]
at org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:165) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:139) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:81) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation.doRun(TransportBulkAction.java:384) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) ~[elasticsearch-6.5.2.jar:6.5.2] címen
at org.elasticsearch.action.bulk.TransportBulkAction.executeBulk(TransportBulkAction.java:496) ~[elasticsearch-6.5.2.jar:6.5.2]
az org.elasticsearch.action.bulk.TransportBulkAction.executeIngestAndBulk(TransportBulkAction.java:243) ~[elasticsearch-6.5.2.jar:6.5.2] címen
at org.elasticsearch.action.bulk.TransportBulkAction.doExecute(TransportBulkAction.java:169) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.bulk.TransportBulkAction.lambda$processBulkIndexIngestRequest$4(TransportBulkAction.java:549) ~[elasticsearch-6.5.2.jar:6.5.2]
az org.elasticsearch.ingest.IngestService$4.doRun(IngestService.java:417) [elasticsearch-6.5.2.jar:6.5.2] címen
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:723) [elasticsearch-6.5.2.jar:6.5.2] címen
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37) [elasticsearch-6.5.2.jar:6.5.2] címen
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]
java.lang.Thread.run(Thread.java:748) [?:1.8.0_222] címen [?:1.8.0_222]
Okta: org.elasticsearch.cluster.block.ClusterBlockException: blokkolva: [FORBIDDEN/12/index read-only / allow delete (api)];
at org.elasticsearch.cluster.block.ClusterBlocks.indexBlockedException(ClusterBlocks.java:183) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockExceptions(TransportReplicationAction.java:810) ~[ elasticsearch-6.5.2.jar:6.5.2]
... Még 21
Elemzés után kiderült, hogy azért van ezAz ES helyén lévő szerver lemezhelye túl alacsony, ha bármely egy vagy több töredéket tartalmazó indexet egy olyan csomóponthoz rendelnek egy olyan koroncban, amely több mint 95%-ot tárol a játékban, az indexet csak olvasható módba kényszerül.
Minden indexbeállítási információ megtekintése megtekintéséhez is:A hiperlink bejelentkezés látható., ahogy az alábbi ábrán látható:
"tudás" : {
"beállítások" : {
"index" : {
"number_of_shards" : "3",
"blokkok" : {
"read_only_allow_delete": "igaz"
},
"provided_name" : "tudás",
"creation_date": "1576206251443",
"number_of_replicas" : "0",
"uuid": "yeSIP_otQo6JQ8ooRdr8hA",
"verzió" : {
"created": "6050299"
}
}
}
}
megoldás
A lemezprobléma megoldása után bővítsd vagy töröld a spam fájlokat, kövesd az alábbi útmutatót.
Állítsd read_only_allow_delete hamisra
Küldhetsz put kérést az elasticsearch-head segítségével:A hiperlink bejelentkezés látható., ahogy az alábbi ábrán látható:
Ez még mindig nem tudja megszabadulni Red egészségi állapotáról,Töröld közvetlenül a ".monitoring-es-6-*" adatot, az állapot egészségessé válik, ahogy az alábbi ábrán látható:
(Vége)
|
Előző:A CentOS minden mappáméretet megszámol, és nagy fájlokat keresKövetkező:Elasticsearch(ES) klaszter egészsége: sárga (6/7) állapot
|
Háziúr|
Közzétéve: 2021-6-15 11:22:58
|
