|
|
Veröffentlicht am 27.01.2021, 23:08:07
|
|
|
|
Mit dem elasticsearch-head-Panel zur Verbindung zu Elasticsearch(ES) fand ich folgenden Fehler:
Cluster-Gesundheit: rot (24 von 31) 
Um Statusinformationen einzusehen, besuchen Sie:Der Hyperlink-Login ist sichtbar.
{
"cluster_name" : "Elasticsearch",
"Status": "Rot",
"timed_out": falsch,
"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
}
Das Head-Plugin wird in verschiedenen Farben angezeigt
1) Grün – der gesündeste Zustand, was bedeutet, dass alle primären und Replik-Splitter verfügbar sind;
2) Gelb – alle primären Splitter sind verfügbar, aber einige Nachbildungssplitter sind nicht verfügbar;
3) Rot – Einige primäre Splitter sind nicht verfügbar. (Derzeit können beim Ausführen der Abfrage noch einige Daten gefunden werden, daher ist es besser, sie schnell zu lösen.) ）
Um den Indexstatus einzusehen, greifen Sie zu:Der Hyperlink-Login ist sichtbar.
.monitoring-es-6-2021.01.22 0 p UNZUGEWIESEN ALLOCATION_FAILED
Erklärung in einem Satz: Unallokierte Shards.
Beim Start von ES werden die Cluster-Splitter nach ständigem Aktualisieren über das Head-Plugin lila, grau und schließlich grün erscheinen.
Warum tritt unzugewiesenes Sharding auf?
Wenn du zum Beispiel keine Shards zuweisen kannst und die Anzahl der Replica-Shards für die Anzahl der Knoten im Cluster überzuweisen hast, bleiben die Shards UNZUGEWIESEN.
Der Fehlercode lautet: ALLOCATION_FAILED.
Mögliche Ursachen für Probleme mit nicht zugewiesenem Sharding?
1) INDEX_CREATED: Nicht zugewiesen aufgrund der API, die den Index erstellt hat.
2) CLUSTER_RECOVERED: Nicht zugewiesen wegen vollständiger Cluster-Wiederherstellung.
3) INDEX_REOPENED: Nicht zugeteilt, weil ein Index geöffnet oder geschlossen wird.
4) DANGLING_INDEX_IMPORTED: Nicht zugeteilt aufgrund des Imports des Hangling-Index.
5) NEW_INDEX_RESTORED: Nicht zugeteilt, da man zu einem neuen Index zurückkehrt.
6) EXISTING_INDEX_RESTORED: Nicht zugeteilt, da man wieder zu einem geschlossenen Index zurückkehrt.
7) REPLICA_ADDED: Nicht zugeordnet, da explizit Replica-Shards hinzugefügt wurden.
8) ALLOCATION_FAILED: Nicht zugeteilt aufgrund eines Shard-Allokationsfehlers.
9) NODE_LEFT: Der Knoten, der den Shard trägt, verlässt den Cluster und wird nicht zugewiesen.
10) REINITIALISIERT: Aufgrund nicht zugeordneter Shards beim Übergang von Anfang zu Initialisierung (z. B. Sharding mit Schatten-Schattenkopien).
11) REROUTE_CANCELLED: Lösen Sie aufgrund eines expliziten Unresail-Befehls.
12) REALLOCATED_REPLICA: Feststellen, dass ein besserer Replikenstandort für die Nutzung kalibriert ist, was zur Aufhebung der bestehenden Kopienzuweisung und Entzuweisung führt.
Melden Sie sich beim Server an und sehen Sie sich die Elasticsearch-(ES)-Protokolle wie folgt an:
Elasticsearch liefert viele Logs, alle im ES_HOME/logs-Verzeichnis. Das Standard-Logging-Level ist INFO. Es liefert moderate Informationen, ist aber darauf ausgelegt, deine Protokolle nicht zu überfordern.
Es gibt eine große Anzahl von Fehlern, wie zum Beispiel:
[2021-01-21T03:33:26,435] [WARN] [o.e.x.m.e.l.LocalExporter] [A_OefhJ] unerwarteter Fehler beim Indexieren des Überwachungsdokuments
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) ~[?:?]
bei java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_222]
bei java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:1.8.0_222]
bei 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]
bei 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]
bei java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485) ~[?:1.8.0_222]
bei 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) ~[?:?]
bei org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.ContextPreservingActionListener.onResponse(ContextPreservingActionListener.java:43) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:85) ~[elasticsearch-6.5.2.jar:6.5.2]
bei org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:81) ~[elasticsearch-6.5.2.jar:6.5.2]
bei org.elasticsearch.action.bulk.TransportBulkAction$BulkRequestModifier.lambda$wrapActionListenerIfNeeded$0(TransportBulkAction.java:607) ~[elasticsearch-6.5.2.jar :6.5.2]
bei org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:60) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.finishHim(TransportBulkAction.java:414) ~[elasticsearch-6.5.2.jar:6.5.2]
bei org.elasticsearch.action.bulk.TransportBulkAction$BulkOperation$1.onFailure(TransportBulkAction.java:409) ~[elasticsearch-6.5.2.jar:6.5.2]
bei 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]
bei 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]
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]
bei 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) ~[?:?]
bei 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]
at org.elasticsearch.action.bulk.TransportBulkAction.executeBulk(TransportBulkAction.java:496) ~[elasticsearch-6.5.2.jar:6.5.2]
at org.elasticsearch.action.bulk.TransportBulkAction.executeIngestAndBulk(TransportBulkAction.java:243) ~[elasticsearch-6.5.2.jar:6.5.2]
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]
at org.elasticsearch.ingest.IngestService$4.doRun(IngestService.java:417) [elasticsearch-6.5.2.jar:6.5.2]
bei org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:723) [elasticsearch-6.5.2.jar:6.5.2]
bei 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]
bei java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Verursacht von: org.elasticsearch.cluster.block.ClusterBlockException: blockiert von: [FORBIDDEN/12/index read-only / allow delete (api)];
bei org.elasticsearch.cluster.block.ClusterBlocks.indexBlockedException(ClusterBlocks.java:183) ~[elasticsearch-6.5.2.jar:6.5.2]
bei org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.handleBlockExceptions(TransportReplicationAction.java:810) ~[ elasticsearch-6.5.2.jar:6.5.2]
... 21 weitere
Nach der Analyse stellte sich heraus, dass es daran lagDer Festplattenspeicher des Servers, auf dem sich der ES befindet, ist zu gering, sobald ein Index mit einem oder mehreren Shards einem Knoten in einer Festplatte zugewiesen wurde, die mehr als 95 % der Daten speichert, wird der Index in den Schreibmodus gezwungen.
Sehen Sie alle Informationen zu den Indexeinstellungen an, um folgende Informationen zu besuchen:Der Hyperlink-Login ist sichtbar., wie in der untenstehenden Abbildung dargestellt:
"Wissen" : {
"Settings" : {
"index" : {
"number_of_shards" : "3",
"Blocks" : {
"read_only_allow_delete" : "wahr"
},
"provided_name": "Wissen",
"creation_date": "1576206251443",
"number_of_replicas" : "0",
"uuid": "yeSIP_otQo6JQ8ooRdr8hA",
"Version" : {
"created : "6050299"
}
}
}
}
Lösung
Nachdem Sie das Festplattenproblem gelöst haben, erweitern oder löschen Sie Junk-Dateien, folgen Sie dem untenstehenden Tutorial.
Stelle read_only_allow_delete auf falsch
Senden Sie eine put-Anfrage mit elasticsearch-head:Der Hyperlink-Login ist sichtbar., wie in der untenstehenden Abbildung dargestellt:
Das kann Reds Gesundheitszustand immer noch nicht beseitigen,Löschen Sie die Daten ".monitoring-es-6-*" direkt, wird der Zustand gesund, wie in der untenstehenden Abbildung gezeigt:
(Ende)
|
Vorhergehend:CentOS zählt jede Ordnergröße und sucht nach großen DateienNächster:Gesundheit des Elasticsearch(ES)-Clusters: gelber (6 von 7) Status
|
Vermieter|
Veröffentlicht am 15.6.2021, 11:22:58
|
