Problembehebung bei Amazon OpenSearch Service

In diesem Thema wird beschrieben, wie Sie häufig auftretende Probleme mit Amazon OpenSearch Service identifizieren und lösen können. Lesen Sie die Informationen in diesem Abschnitt, bevor Sie sich an den AWS -Support wenden.

Ich kann nicht auf OpenSearch Dashboards zugreifen

Der OpenSearch Dashboards-Endpunkt unterstützt keine signierten Anfragen. Wenn durch die Zugriffskontrollrichtlinie Ihrer Domain nur Zugriff auf bestimmte IAM-Rollen gewährt wird und Sie Amazon-Cognito-Authentifizierung nicht konfiguriert haben, erhalten Sie möglicherweise folgende Fehlermeldung, wenn Sie versuchen, auf Dashboards zuzugreifen:

"User: anonymous is not authorized to perform: es:ESHttpGet"

Wenn Ihre OpenSearch Service-Domain VPC-Zugriff verwendet, erhalten Sie diesen Fehler möglicherweise nicht, aber es kann zu einem Timeout bei der Anfrage kommen. Informationen zur Behebung dieses Problems und zu den verschiedenen verfügbaren Konfigurationsoptionen finden Sie unter Steuern des Zugriffs auf Dashboards OpenSearch Zugriffsrichtlinien für VPC-Domänen und Identity and Access Management in Amazon OpenSearch Service.

Zugriff auf VPC-Domain nicht möglich

Siehe Zugriffsrichtlinien für VPC-Domänen und Testen von VPC-Domänen.

Cluster im schreibgeschützten Zustand

Im Vergleich zu früheren Elasticsearch-Versionen OpenSearch und Elasticsearch 7. x verwendet ein anderes System für die Cluster-Koordination. Wenn der Cluster in diesem neuen System das Quorum verliert, ist der Cluster erst verfügbar, wenn Sie Maßnahmen ergreifen. Der Verlust des Quorums kann zwei Formen annehmen:

• Wenn Ihr Cluster dedizierte Hauptknoten verwendet, tritt ein Quorum-Verlust auf, wenn die Hälfte oder mehr nicht verfügbar sind.

• Wenn Ihr Cluster keine dedizierten Hauptknoten verwendet, tritt ein Quorum-Verlust auf, wenn die Hälfte oder mehr Ihrer Datenknoten nicht verfügbar sind.

Wenn ein Quorumverlust auftritt und Ihr Cluster mehr als einen Knoten hat, stellt der OpenSearch Dienst das Quorum wieder her und versetzt den Cluster in einen schreibgeschützten Zustand. Sie haben hierfür zwei Möglichkeiten:

• Entfernen Sie den schreibgeschützten Status und verwenden Sie den Cluster wie er ist.

• Stellen Sie den Cluster oder einzelne Indizes aus einem Snapshot wieder her.

Wenn Sie den Cluster vorziehen, wie er ist, überprüfen Sie mit der folgenden Anforderung, ob der Cluster-Zustand grün ist:

GET _cat/health?v

Wenn der Cluster-Zustand rot ist, empfehlen wir, den Cluster aus einem Snapshot wiederherzustellen. Informationen zur Fehlerbehebung finden Sie auch unter Roter Cluster-Status. Wenn der Cluster-Zustand grün ist, überprüfen Sie mit der folgenden Anforderung, ob alle erwarteten Indizes vorhanden sind:

GET _cat/indices?v

Führen Sie dann einige Suchanfragen aus, um zu überprüfen, ob die erwarteten Daten vorhanden sind. Wenn dies der Fall ist, können Sie den schreibgeschützten Status mithilfe der folgenden Anforderung entfernen:

PUT _cluster/settings
{
  "persistent": {
    "cluster.blocks.read_only": false
  }
}

Wenn ein Quorumverlust auftritt und Ihr Cluster nur aus einem Knoten besteht, ersetzt OpenSearch Service den Knoten und versetzt den Cluster nicht in einen schreibgeschützten Zustand. Andernfalls sind Ihre Optionen gleich: Verwenden Sie den Cluster unverändert oder stellen Sie ihn aus einem Snapshot wieder her.

In beiden Situationen sendet OpenSearch Service zwei Ereignisse an Ihren. AWS Health Dashboard Das erste informiert Sie über den Verlust des Quorums. Das zweite Ereignis tritt ein, nachdem OpenSearch Service das Quorum erfolgreich wiederhergestellt hat. Weitere Informationen zur Verwendung von finden Sie im AWS Health Benutzerhandbuch. AWS Health Dashboard

Roter Cluster-Status

Ein roter Clusterstatus bedeutet, dass mindestens ein primärer Shard und seine Replikate keinem Knoten zugewiesen sind. OpenSearch Der Dienst versucht weiterhin, automatische Snapshots aller Indizes unabhängig von ihrem Status zu erstellen, aber die Snapshots schlagen fehl, solange der rote Clusterstatus bestehen bleibt.

Die häufigsten Ursachen für einen roten Clusterstatus sind ausgefallene Clusterknoten und OpenSearch Prozessabstürze aufgrund einer kontinuierlich hohen Verarbeitungslast.

Anmerkung

OpenSearch Der Service speichert automatische Snapshots unabhängig vom Clusterstatus 14 Tage lang. Wenn der rote Cluster-Status länger als zwei Wochen anhält, wird daher der letzte fehlerfreie automatisierte Snapshot gelöscht und Sie könnten die Daten Ihres Clusters dauerhaft verlieren. Wenn Ihre OpenSearch Service-Domain den Cluster-Status Rot annimmt, kontaktieren Sie AWS Support möglicherweise, um zu fragen, ob Sie das Problem selbst lösen möchten oder ob Sie möchten, dass Ihnen das Support-Team weiterhilft. Sie können einen CloudWatch Alarm einrichten, der Sie benachrichtigt, wenn ein roter Clusterstatus eintritt.

Letztlich führen rote Shards zu roten Clustern; und rote Indizes verursachen rote Shards. Um die Indizes zu identifizieren, die den roten Clusterstatus verursachen, OpenSearch gibt es einige hilfreiche APIs.

• GET /_cluster/allocation/explain wählt den ersten nicht zugewiesenen Shard aus und erklärt, warum er keinem Knoten zugeordnet werden kann:

  {
      "index": "test4",
      "shard": 0,
      "primary": true,
      "current_state": "unassigned",
      "can_allocate": "no",
      "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes"
  }

• GET /_cat/indices?v zeigt den Zustand, die Anzahl der Dokumente und die Festplattennutzung für jeden Index an:

  health status index            uuid                   pri rep docs.count docs.deleted store.size pri.store.size
  green  open   test1            30h1EiMvS5uAFr2t5CEVoQ   5   0        820            0       14mb           14mb
  green  open   test2            sdIxs_WDT56afFGu5KPbFQ   1   0          0            0       233b           233b
  green  open   test3            GGRZp_TBRZuSaZpAGk2pmw   1   1          2            0     14.7kb          7.3kb
  red    open   test4            BJxfAErbTtu5HBjIXJV_7A   1   0
  green  open   test5            _8C6MIXOSxCqVYicH3jsEA   1   0          7            0     24.3kb         24.3kb

Das Löschen von roten Indizes ist die schnellste Möglichkeit, einen roten Cluster-Status zu beheben. Abhängig vom Grund für den roten Cluster-Status können Sie dann Ihre OpenSearch Service-Domain skalieren, um größere Instance-Typen, mehr Instances oder mehr EBS-basierten Speicher zu verwenden, und versuchen, die problematischen Indizes neu zu erstellen.

Sollte ein fehlerhafter Index nicht löschbar sein, können Sie einen Snapshot wiederherstellen, Dokumente aus dem Index löschen, die Indexeinstellungen ändern, die Anzahl der Replikate verringern oder andere Indizes löschen, um Speicherplatz freizusetzen. Der wichtige Schritt besteht darin, den roten Clusterstatus zu beheben, bevor Sie Ihre Service-Domain neu konfigurieren. OpenSearch Falls eine Domain mit rotem Cluster-Status neu konfiguriert wird, kann sich das Problem verschlimmern und dazu führen, dass die Domain im Konfigurationsstatus Processing (Verarbeitung) verharrt, bis der rote Status behoben ist.

Automatische Behebung von roten Clustern

Wenn der Status Ihres Clusters länger als eine Stunde ununterbrochen rot ist, versucht OpenSearch Service, das Problem automatisch zu beheben, indem nicht zugewiesene Shards umgeleitet oder Daten aus früheren Snapshots wiederhergestellt werden.

Wenn ein oder mehrere rote Indizes nicht repariert werden können und der Clusterstatus insgesamt 14 Tage lang rot bleibt, ergreift OpenSearch Service nur dann weitere Maßnahmen, wenn der Cluster mindestens eines der folgenden Kriterien erfüllt:

• Hat nur eine Availability Zone

• Hat keine dedizierten Hauptknoten

• Enthält Burstable-Instance-Typen (T2 oder T3)

Wenn Ihr Cluster eines dieser Kriterien erfüllt, sendet Ihnen OpenSearch Service in den nächsten 7 Tagen täglich Benachrichtigungen, in denen erklärt wird, dass alle nicht zugewiesenen Shards gelöscht werden, wenn Sie diese Indizes nicht korrigieren. Wenn Ihr Clusterstatus nach 21 Tagen immer noch rot ist, löscht OpenSearch Service die nicht zugewiesenen Shards (Speicher und Rechenleistung) in allen roten Indizes. Für jedes dieser Ereignisse erhalten Sie im Benachrichtigungsbereich der OpenSearch Servicekonsole Benachrichtigungen. Weitere Informationen finden Sie unter Ereignisse zum Cluster-Zustand.

Wiederherstellung nach einem kontinuierlich starken Workload

Um zu ermitteln, ob ein roter Cluster-Status durch einen kontinuierlich starken Workload auf einem Datenknoten verursacht wird, überwachen Sie die folgenden Cluster-Metriken.

Relevante Metrik	Beschreibung	Wiederherstellung
JVM MemoryPressure	Gibt den Prozentsatz des Java-Heap an, der für alle Datenknoten in einem Cluster verwendet wird. Zeigen Sie die Statistik Maximum für diese Metrik an und achten Sie auf eine immer kleiner werdende Verringerung der Speicherbelastung, während der Java Garbage Collector keine ausreichende Arbeitsspeichermenge mehr zurückgewinnt. Dieses Muster wird wahrscheinlich durch komplexe Abfragen oder große Datenfelder verursacht. x86-Instance-Typen verwenden den Garbage Collector „Concurrent Mark Sweep (CMS)“, der zusammen mit Anwendungs-Threads ausgeführt wird, um Pausen kurz zu halten. Wenn CMS während seiner normalen Sammelvorgänge nicht ausreichend Arbeitsspeicher zurückgewinnen kann, löst es eine vollständige Garbage Collection aus, was zu langen Anwendungspausen und Auswirkungen auf die Clusterstabilität führen kann. ARM-basierte Graviton-Instance-Typen verwenden den Garbage-First (G1) Garbage Collector, der CMS ähnlich ist, jedoch zusätzliche kurze Pausen und Heap-Defragmentierung verwendet, um die Notwendigkeit vollständiger Garbage Collections weiter zu reduzieren. In beiden Fällen OpenSearch stürzt der Speicherverbrauch mit einem Speichermangel ab, wenn der Speicherverbrauch über das hinausgeht, was der Garbage-Collector bei vollständigen Garbage-Collections zurückgewinnen kann. Bei allen Instance-Typen gilt als Faustregel, die Nutzung unter 80 % zu halten. Die _nodes/stats/jvm-API bietet eine hilfreiche Übersicht über die JVM-Statistiken, Speicherpoolnutzung und Garbage Collection-Informationen: GET domain-endpoint/_nodes/stats/jvm?pretty	Legen Sie Arbeitsspeicher-Leistungsschutzschalter für die JVM fest. Weitere Informationen finden Sie unter JVM OutOfMemoryError. Wenn das Problem weiterhin besteht, löschen Sie unnötige Indizes, reduzieren Sie die Anzahl oder Komplexität der Anforderungen an die Domain, fügen Sie Instances hinzu oder verwenden Sie größere Instance-Typen.
CPUUtilization	Gibt den Prozentsatz der CPU-Ressourcen an, die für Datenknoten in einem Cluster verwendet werden. Sehen Sie sich die Statistik Maximum für diese Metrik an und suchen Sie nach einem kontinuierlichen Muster für starke Nutzung.	Fügen Sie Datenknoten hinzu oder erhöhen Sie die Größe der Instance-Typen vorhandener Datenknoten.
Knoten	Gibt die Anzahl der Knoten in einem Cluster an. Sehen Sie sich die Statistik Maximum für diese Metrik an. Dieser Wert schwankt, wenn der Service eine neue Flotte an Instances für einen Cluster bereitstellt.	Fügen Sie Datenknoten hinzu.

Gelber Cluster-Status

Ein gelber Cluster-Status bedeutet, dass die primären Shards für alle Indizes zu Knoten in einem Cluster zugewiesen sind, die Replikat-Shards für mindestens einen Index jedoch nicht. Cluster mit einem Knoten werden immer mit einem gelben Clusterstatus initialisiert, da es keinen anderen Knoten gibt, dem der OpenSearch Dienst ein Replikat zuweisen kann. Erhöhen Sie die Knotenanzahl, um einen grünen Cluster-Status zu erreichen. Weitere Informationen finden Sie unter Dimensionierung von Amazon OpenSearch Service-Domains.

Cluster mit mehreren Knoten können nach dem Erstellen eines neuen Index oder nach einem Knotenausfall kurzzeitig einen gelben Clusterstatus aufweisen. Dieser Status löst sich von selbst auf, wenn Daten im gesamten Cluster OpenSearch repliziert werden. Ein Mangel an Festplattenspeicher kann auch zu einem gelben Cluster-Status führen; Der Cluster kann Replikat-Shards nur verteilen, wenn die Knoten über ausreichend Speicherplatz verfügen, um sie aufzunehmen.

ClusterBlockException

Unter Umständen erhalten Sie aus folgenden Gründen den Fehler ClusterBlockException.

Zu wenig verfügbarer Speicherplatz

Wenn ein oder mehrere Knoten in Ihrem Cluster über Speicherplatz verfügen, der unter dem Mindestwert von 1) 20% des verfügbaren Speicherplatzes oder 2) 20 GiB Speicherplatz liegt, können grundlegende Schreibvorgänge wie das Hinzufügen von Dokumenten und das Erstellen von Indizes fehlschlagen. Berechnung der Speicheranforderungenbietet eine Zusammenfassung darüber, wie OpenSearch Service Festplattenspeicher verwendet.

Um Probleme zu vermeiden, sollten Sie die FreeStorageSpace Metrik in der OpenSearch Servicekonsole überwachen und CloudWatch Alarme einrichten, die ausgelöst werden, wenn FreeStorageSpace ein bestimmter Schwellenwert unterschritten wird. GET /_cat/allocation?vbietet außerdem eine nützliche Zusammenfassung der Shard-Zuweisung und der Festplattennutzung. Um Probleme im Zusammenhang mit fehlendem Speicherplatz zu beheben, skalieren Sie Ihre OpenSearch Service-Domain so, dass sie größere Instance-Typen, mehr Instanzen oder mehr EBS-basierten Speicher verwendet.

Hoher JVM-Speicherdruck

Wenn die MemoryPressureJVM-Metrik 30 Minuten lang 92% überschreitet, löst der OpenSearch Service einen Schutzmechanismus aus und blockiert alle Schreibvorgänge, um zu verhindern, dass der Cluster den roten Status erreicht. Wenn der Schutz aktiviert ist, schlagen Schreibvorgänge mit einem ClusterBlockException-Fehler fehl, es können keine neuen Indizes erstellt werden und der Fehler IndexCreateBlockException wird ausgegeben.

Wenn die MemoryPressureJVM-Metrik fünf Minuten lang auf 88% oder weniger zurückgeht, ist der Schutz deaktiviert und Schreibvorgänge in den Cluster werden entsperrt.

Ein hoher JVM-Speicherdruck kann durch Spitzen in der Anzahl der Anfragen an den Cluster, unausgewogene Shard-Zuweisungen über Knoten hinweg, zu viele Shards in einem Cluster, Felddaten- oder Indexzuordnungsexplosionen oder Instance-Typen, die eingehende Lasten nicht bewältigen können, verursacht werden. Er kann außerdem auch durch die Verwendung von Aggregationen, Platzhaltern oder großen Zeitbereichen in Abfragen verursacht werden.

Um den Datenverkehr zum Cluster zu reduzieren und Probleme mit hohem JVM-Speicherdruck zu beheben, versuchen Sie eine oder mehrere der folgenden Möglichkeiten:

• Skalieren Sie die Domain so, dass die maximale Heap-Größe pro Knoten 32 GB beträgt.

• Reduzieren Sie die Anzahl der Shards, indem Sie alte oder nicht verwendete Indizes löschen.

• Leeren Sie den Datencache mit dem API-Vorgang POST index-name/_cache/clear?fielddata=true. Beachten Sie, dass das Löschen des Caches laufende Abfragen beeinträchtigen kann.

Um künftig einen hohen JVM-Speicherbedarf zu vermeiden, sollten Sie sich allgemein an die folgenden bewährten Methoden halten:

• Vermeiden Sie das Aggregieren in Textfeldern oder ändern Sie den Zuordnungstyp für Ihre Indizes in keyword.

• Optimieren Sie Such- und Indizierungsanforderungen durch die Auswahl der richtigen Anzahl von Shards.

• Richten Sie Index State Management (ISM)-Richtlinien ein, um nicht verwendete Indizes regelmäßig zu entfernen.

Fehler bei der Migration zu Multi-AZ mit Standby

Die folgenden Probleme können auftreten, wenn Sie eine bestehende Domain zu Multi-AZ mit Standby migrieren.

Erstellen eines Indexes, einer Indexvorlage oder einer ISM-Richtlinie während der Migration von Domänen ohne Standby zu Domänen mit Standby

Wenn Sie bei der Migration einer Domain von Multi-AZ ohne Standby zu mit Standby einen Index erstellen und die Indexvorlage oder ISM-Richtlinie nicht den empfohlenen Richtlinien für das Kopieren von Daten entspricht, kann dies zu Dateninkonsistenzen führen und die Migration kann fehlschlagen. Um diese Situation zu vermeiden, erstellen Sie den neuen Index mit einer Anzahl von Datenkopien (einschließlich primärer Knoten und Replikate), die ein Vielfaches von drei ist. Sie können den Migrationsfortschritt mithilfe der API überprüfen. DescribeDomainChangeProgress Wenn Sie auf einen Fehler bei der Anzahl der Replikate stoßen, beheben Sie den Fehler und wenden Sie sich dann an den AWS Support, um die Migration erneut zu versuchen.

Falsche Anzahl von Datenkopien

Wenn Sie nicht über die richtige Anzahl von Datenkopien in Ihrer Domain verfügen, schlägt die Migration zu Multi-AZ mit Standby fehl.

JVM OutOfMemoryError

Ein JVM-OutOfMemoryError bedeutet in der Regel, dass einer der folgenden JVM-Leistungsschutzschalter erreicht wurde.

Leistungsschutzschalter	Beschreibung	Eigenschaft der Cluster-Einstellung
Übergeordneter Schalter	Gesamter JVM-Heap-Arbeitsspeicher in Prozent, der für alle Leitungsschutzschalter zulässig ist. Der Standardwert ist 95 %.	indices.breaker.total.limit
Felddaten-Schutzschalter	Prozentsatz des JVM-Heap-Arbeitsspeichers, der für das Laden eines einzelnen Datenfelds in den Arbeitsspeicher zulässig ist. Der Standardwert lautet 40%. Wenn Sie Daten mit großen Feldern hochladen, müssen Sie dieses Limit möglicherweise erhöhen.	indices.breaker.fielddata.limit
Anforderungs-Schutzschalter	Prozentsatz des JVM-Heap-Arbeitsspeichers, der zulässig ist für Datenstrukturen, die zur Antwort auf eine Serviceanforderung verwendet werden. Der Standardwert lautet 60%. Wenn Ihre Serviceanfragen die Berechnung von Aggregationen beinhalten, müssen Sie dieses Limit möglicherweise erhöhen.	indices.breaker.request.limit

Fehlgeschlagene Cluster-Knoten

Bei Amazon-EC2-Instances kann es zu unerwarteten Beendigungen und Neustarts kommen. In der Regel startet OpenSearch Service die Knoten für Sie neu. Es ist jedoch möglich, dass ein oder mehrere Knoten in einem OpenSearch Cluster weiterhin ausgefallen sind.

Um nach diesem Zustand zu suchen, öffnen Sie Ihr Domain-Dashboard in der OpenSearch Servicekonsole. Wählen Sie die Registerkarte Clusterzustand und anschließend die Gesamte Knoten-Metrik aus. Überprüfen Sie, ob die gemeldete Anzahl an Knoten geringer ist als die Anzahl, die Sie für Ihren Cluster konfiguriert haben. Wenn die Metrik zeigt, dass ein oder mehrere Knoten länger als einen Tag ausgefallen sind, wenden Sie sich bitte an den AWS -Support.

Sie können auch einen CloudWatch Alarm einrichten, der Sie benachrichtigt, wenn dieses Problem auftritt.

Anmerkung

Die Knoten-Metrik ist während Änderungen an Ihrer Cluster-Konfiguration und routinemäßigen Wartungen des Services nicht genau. Dieses Verhalten wird erwartet. Die Metrik wird die richtige Anzahl an Cluster-Knoten in Kürze angeben. Weitere Informationen hierzu finden Sie unter Konfigurationsänderungen in Amazon OpenSearch Service vornehmen.

Um Ihre Cluster vor unerwarteten Knotenabbrüchen und Neustarts zu schützen, erstellen Sie mindestens ein Replikat für jeden Index in Ihrer OpenSearch Service-Domain.

Maximales Shard-Limit überschritten

OpenSearch sowie 7. x-Versionen von Elasticsearch haben eine Standardeinstellung von nicht mehr als 1.000 Shards pro Knoten. OpenSearch/Elasticsearch gibt einen Fehler aus, wenn eine Anfrage, z. B. die Erstellung eines neuen Indexes, dazu führen würde, dass Sie dieses Limit überschreiten. Wenn dieser Fehler auftritt, haben Sie mehrere Möglichkeiten:

• Fügen Sie dem Cluster weitere Datenknoten hinzu.

• Erhöhen Sie die _cluster/settings/cluster.max_shards_per_node-Einstellung.

• Verwenden Sie die _shrink-API, um die Anzahl der Shards auf dem Knoten zu reduzieren.

Domain bleibt im Bearbeitungsstatus hängen

Ihre OpenSearch Service-Domain wechselt in den Status „In Bearbeitung“, wenn sie sich mitten in einer Konfigurationsänderung befindet. Wenn Sie eine Konfigurationsänderung einleiten, ändert sich der Domänenstatus in „In Bearbeitung“, während OpenSearch Service eine neue Umgebung erstellt. In der neuen Umgebung startet der OpenSearch Service einen neuen Satz geeigneter Knoten (z. B. Data, Master oder UltraWarm). Nachdem die Migration abgeschlossen ist, werden die älteren Knoten beendet.

Der Cluster kann im Status „Verarbeitung“ hängen bleiben, wenn eine der folgenden Situationen eintritt:

• Ein neuer Satz von Datenknoten kann nicht gestartet werden.

• Die Shard-Migration auf den neuen Satz von Datenknoten ist nicht erfolgreich.

• Die Validierungsprüfung ist mit Fehlern fehlgeschlagen.

Detaillierte Lösungsschritte für jede dieser Situationen finden Sie unter Warum befindet sich meine Amazon OpenSearch Service-Domain im Status „In Bearbeitung“? .

Niedrige EBS-Burst-Balance

OpenSearch Der Service sendet Ihnen eine Konsolenbenachrichtigung, wenn der EBS-Burst-Saldo auf einem Ihrer General Purpose (SSD) -Volumes unter 70% liegt, und eine Folgebenachrichtigung, wenn der Saldo unter 20% fällt. Um dieses Problem zu beheben, können Sie entweder Ihren Cluster hochskalieren oder die Lese- und Schreib-IOPS reduzieren, sodass die Burst-Balance gutgeschrieben werden kann. Das Burst-Balance bleibt für Domains mit GP3-Volume-Typen und Domains mit GP2-Volumes mit einer Volume-Größe von über 1.000 GiB bei 0. Weitere Informationen finden Sie unter universelle SSD-Volumes (gp2). Sie können den EBS-Burst-Saldo anhand der BurstBalance CloudWatch Metrik überwachen.

Prüfungsprotokolle können nicht aktiviert werden

Wenn Sie versuchen, die Veröffentlichung von Audit-Protokollen über die OpenSearch Service-Konsole zu aktivieren, tritt möglicherweise der folgende Fehler auf:

Die für die Protokollgruppe CloudWatch Logs angegebene Ressourcenzugriffsrichtlinie gewährt Amazon OpenSearch Service nicht genügend Berechtigungen, um einen Protokollstream zu erstellen. Überprüfen Sie die Ressourcenzugriffsrichtlinie.

Wenn dieser Fehler auftritt, überprüfen Sie, ob das resource-Element Ihrer Richtlinie den richtigen Protokollgruppen-ARN enthält. Führen Sie in diesem Fall die folgenden Schritte aus:

1. Warten Sie einige Minuten.

2. Aktualisieren Sie die Seite in Ihrem Webbrowser.

3. Wählen Sie Vorhandene Gruppe auswählen.

4. Wählen Sie für Vorhandene Protokollgruppe die Protokollgruppe aus, die Sie erstellt haben, bevor Sie die Fehlermeldung erhalten.

5. Wählen Sie im Abschnitt Zugriffsrichtlinie die Option Vorhandene Richtlinie auswählen aus.

6. Wählen Sie für Vorhandene Richtlinie die Richtlinie aus, die Sie erstellt haben, bevor Sie die Fehlermeldung erhalten.

7. Wählen Sie Enable (Aktivieren) aus.

Wenn der Fehler nach mehrmaligem Wiederholen des Vorgangs weiterhin besteht, wenden Sie sich an den AWS -Support.

Schließen des Indexes nicht möglich

OpenSearch Der Service unterstützt die _closeAPI nur für OpenSearch Elasticsearch-Versionen 7.4 und höher. Wenn Sie eine ältere Version verwenden und einen Index aus einem Snapshot wiederherstellen, können Sie den vorhandenen Index löschen (vor oder nach der erneuten Indizierung).

Prüfungen für Client-Lizenz

Die Standarddistributionen von Logstash und Beats beinhalten eine Prüfung der eigenen Lizenz und können keine Verbindung zur Open-Source-Version von herstellen. OpenSearch Stellen Sie sicher, dass Sie die Apache 2.0 (OSS) -Distributionen dieser Clients mit Service verwenden. OpenSearch

Drosselung anfordern

Wenn Sie dauerhafte 403 Request throttled due to too many requests- oder 429 Too Many Requests-Fehler erhalten, sollten Sie eine vertikale Skalierung in Betracht ziehen. Amazon OpenSearch Service drosselt Anfragen, wenn die Nutzlast dazu führen würde, dass die Speichernutzung die maximale Größe des Java-Heaps überschreitet.

SSH im Knoten nicht möglich

Sie können SSH nicht verwenden, um auf einen der Knoten in Ihrem OpenSearch Cluster zuzugreifen, und Sie können Änderungen nicht direkt vornehmen. opensearch.yml Verwenden Sie stattdessen die Konsole oder die SDKs AWS CLI, um Ihre Domain zu konfigurieren. Mithilfe der OpenSearch REST-APIs können Sie auch einige Einstellungen auf Clusterebene angeben. Weitere Informationen finden Sie in der Amazon OpenSearch Service API-Referenz undUnterstützte Vorgänge in Amazon OpenSearch Service.

Wenn Sie mehr Einblick in die Leistung des Clusters benötigen, können Sie Fehlerprotokolle und langsame Protokolle unter veröffentlichen CloudWatch.

Snapshot-Fehler „Nicht gültig für die Speicherklasse des Objekts“

OpenSearch Service-Snapshots unterstützen die Speicherklasse S3 Glacier nicht. Dieser Fehler kann auftreten, wenn Sie versuchen, Snapshots aufzulisten, wenn Ihr S3-Bucket eine Lebenszyklusregel enthält, die einen Übergang der Objekte in die Speicherklasse S3 Glacier bewirkt.

Wenn Sie einen Snapshot aus einem Bucket wiederherstellen müssen, stellen Sie die Objekte aus S3 Glacier wieder her, kopieren Sie die Objekte in einen neuen Bucket und registrieren Sie den neuen Bucket als Snapshot-Repository.

Ungültiger Host-Header

OpenSearch Der Service erfordert, dass die Clients dies Host in den Anforderungsheadern angeben. Ein gültiger Host-Wert ist der Domain-Endpunkt ohne https://, z. B.:

Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com

Wenn Sie bei einer Anfrage eine Invalid Host Header Fehlermeldung erhalten, überprüfen Sie, ob Ihr Client oder Proxy den OpenSearch Service-Domänenendpunkt (und nicht beispielsweise seine IP-Adresse) im Host Header enthält.

Ungültiger M3-Instance-Typ

OpenSearch Der Service unterstützt das Hinzufügen oder Ändern von M3-Instances zu bestehenden Domains, auf denen die Elasticsearch-Versionen 6.7 und höher ausgeführt OpenSearch werden, nicht. Sie können weiterhin M3-Instances mit Elasticsearch 6.5 und früher verwenden.

Es wird empfohlen, einen neueren Instance-Typ auszuwählen. Für Domains, die auf Elasticsearch 6.7 oder höher laufen OpenSearch , gelten die folgenden Einschränkungen:

• Wenn Ihre vorhandene Domain keine M3-Instances verwendet, können Sie nicht mehr zu diesen wechseln.

• Wenn Sie eine vorhandene Domain von einem M3-Instance-Typ in einen anderen Instance-Typ ändern, können Sie nicht zurückwechseln.

Hot Queries funktionieren nach der Aktivierung nicht mehr UltraWarm

Wenn Sie die Option für eine Domäne aktivieren und die search.max_buckets Einstellung nicht bereits außer Kraft gesetzt wurde, legt OpenSearch Service den Wert automatisch UltraWarm auf fest, um 10000 zu verhindern, dass speicherintensive Abfragen warme Knoten überlasten. Wenn Ihre Hot-Abfragen mehr als 10.000 Buckets verwenden, funktionieren sie möglicherweise nicht mehr, wenn Sie sie aktivieren. UltraWarm

Da Sie diese Einstellung aufgrund des verwalteten Charakters von Amazon OpenSearch Service nicht ändern können, müssen Sie einen Support-Fall eröffnen, um das Limit zu erhöhen. Limiterhöhungen erfordern kein Premium-Support-Abonnement.

Nach einem Upgrade ist kein Downgrade möglich

Direkte Upgrades können nicht mehr rückgängig gemacht werden. Wenn Sie sich jedoch an den AWS Support wenden, können die Mitarbeiter Ihnen helfen, den automatischen Pre-Upgrade-Snapshot auf einer neuen Domain wiederherzustellen. Wenn Sie beispielsweise eine Domain von Elasticsearch 5.6 auf 6.4 aktualisieren, kann der AWS Support Ihnen helfen, den Snapshot vor dem Upgrade auf einer neuen Elasticsearch 5.6-Domain wiederherzustellen. Wenn Sie einen manuellen Snapshot der ursprünglichen Domain erstellen würden, könnten Sie diesen Schritt selbst ausführen.

Erforderliche Zusammenfassung der Domains für alle AWS-Regionen

Das folgende Skript verwendet den Amazon EC2 AWS CLI EC2-Befehl describe-regions, um eine Liste aller Regionen zu erstellen, in denen der OpenSearch Service verfügbar sein könnte. Dann ruft es list-domain-namesfür jede Region auf:

for region in `aws ec2 describe-regions --output text | cut -f4`
do
    echo "\nListing domains in region '$region':"
    aws opensearch list-domain-names --region $region --query 'DomainNames'
done

Sie erhalten die folgende Ausgabe für jede Region:

Listing domains in region:'us-west-2'...
[
  {
    "DomainName": "sample-domain"
  }
]

Regionen, in denen der OpenSearch Dienst nicht verfügbar ist, geben „Es konnte keine Verbindung zur Endpunkt-URL hergestellt werden“ zurück.

Browserfehler bei der Verwendung von OpenSearch Dashboards

Ihr Browser verpackt Dienstfehlermeldungen in HTTP-Antwortobjekten, wenn Sie Dashboards verwenden, um Daten in Ihrer OpenSearch Service-Domain anzuzeigen. Sie können die gängigen Entwickler-Tools in Web-Browsern, wie den Entwicklermodus in Chrome, verwenden, um die zugrundeliegenden Servicefehler anzuzeigen und Ihre Debugging-Bemühungen zu unterstützen.

So zeigen Sie Servicefehler in Chrome an

1. Wählen Sie im Menü Anzeigen, Entwickler, Entwickler-Tools aus.

2. Wählen Sie die Registerkarte Network (Netzwerk) aus.

3. Wählen Sie in der Spalte Status eine beliebige HTTP-Sitzung mit dem Status 500 aus.

So zeigen Sie Servicefehler in Firefox an

1. Wählen Sie im Menü Tools, Web Developer (Web-Entwickler), Network (Netzwerk) aus.

2. Wählen Sie eine HTTP-Sitzung mit dem Status 500.

3. Wählen Sie die Registerkarte Response (Antwort) aus, um die Serviceantwort anzuzeigen.

Knoten-Shard und Speicherversatz

Knoten-Shard-Versatz liegt vor, wenn ein oder mehrere Knoten innerhalb eines Clusters deutlich mehr Shards als die anderen Knoten haben. Knoten-Speicherversatz liegt vor, wenn ein oder mehrere Knoten innerhalb eines Clusters deutlich mehr Speicher (disk.indices) haben als die anderen Knoten. Während diese beiden Bedingungen vorübergehend auftreten können, z. B. wenn eine Domain einen Knoten ersetzt hat und ihm immer noch Shards zuweist, sollten Sie sie beheben, wenn sie bestehen bleiben.

Um beide Arten von Versatz zu erkennen, führen Sie den API-Vorgang _cat/allocation aus und vergleichen Sie die Einträge shards und disk.indices in der Antwort:

 shards    | disk.indices  | disk.used  | disk.avail   | disk.total   | disk.percent |  host     | ip       | node
    264    |      465.3mb  |   229.9mb  |      1.4tb   |      1.5tb   |            0 |  x.x.x.x  | x.x.x.x  | node1
    115    |        7.9mb  |    83.7mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node2
    264    |      465.3mb  |   235.3mb  |      1.4tb   |      1.5tb   |            0 |  x.x.x.x  | x.x.x.x  | node3
    116    |        7.9mb  |    82.8mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node4
    115    |        8.4mb  |      85mb  |     49.1gb   |     49.2gb   |            0 |  x.x.x.x  | x.x.x.x  | node5

Während ein gewisser Speicherversatz normal ist, ist alles über 10 % des Durchschnitts signifikant. Wenn die Shard-Verteilung verzerrt ist, kann die Nutzung der CPU-, Netzwerk- und Festplattenbandbreite ebenfalls verzerrt werden. Da mehr Daten im Allgemeinen mehr Indizierungs- und Suchvorgänge bedeuten, sind die schwersten Knoten in der Regel auch die Knoten mit der höchsten Ressourcenbelastung, während die leichteren Knoten eine nicht ausgelastete Kapazität darstellen.

Abhilfe: Verwenden Sie Shard-Zählungen, die ein Vielfaches der Datenknotenanzahl sind, um sicherzustellen, dass jeder Index gleichmäßig über die Datenknoten verteilt wird.

Index-Shard und Speicherversatz

Index-Shard-Versatz liegt vor, wenn ein oder mehrere Knoten mehr Shards eines Index enthalten als die anderen Knoten. Index-Speicher-Versatz liegt vor, wenn ein oder mehrere Knoten eine unverhältnismäßig große Menge des Gesamtspeichers eines Index halten.

Indexversatz ist schwieriger zu erkennen als Knoten-Versatz, da er eine gewisse Manipulation der _cat/shards-API-Ausgabe erfordert. Untersuchen Sie den Indexversatz, wenn es Anzeichen für einen Versatz in den Cluster- oder Knotenmetriken gibt. Im Folgenden finden Sie häufige Anzeichen für Indexversatz:

• HTTP-429-Fehler, die auf einer Teilmenge von Datenknoten auftreten

• Ungleiche Index- oder Suchoperationen-Warteschlangen auf den Datenknoten

• Ungleichmäßige JVM-Heap- und/oder CPU-Auslastung auf den Datenknoten

Abhilfe: Verwenden Sie Shard-Zählungen, die ein Vielfaches der Datenknotenanzahl sind, um sicherzustellen, dass jeder Index gleichmäßig über die Datenknoten verteilt wird. Wenn Sie immer noch eine Verzerrung des Indexspeichers oder des Shards sehen, müssen Sie möglicherweise eine Shard-Neuzuweisung erzwingen, die bei jeder Bereitstellung Ihrer Service-Domain in Blau/Grün erfolgt. OpenSearch

Unautorisierte Operation nach dem Auswählen des VPC-Zugriffs

Wenn Sie mit der OpenSearch Service-Konsole eine neue Domain erstellen, haben Sie die Möglichkeit, VPC oder Public Access auszuwählen. Wenn Sie VPC-Zugriff wählen, fragt der OpenSearch Service nach VPC-Informationen ab und schlägt fehl, wenn Sie nicht über die entsprechenden Berechtigungen verfügen:

You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation

Damit diese Abfrage durchgeführt werden kann, benötigen Sie Zugriff auf die Operationen ec2:DescribeVpcs, ec2:DescribeSubnets und ec2:DescribeSecurityGroups. Diese Voraussetzung gilt nur für die Konsole. Wenn Sie die AWS CLI verwenden, um eine Domain mit einem VPC-Endpunkt zu erstellen und zu konfigurieren, benötigen Sie keinen Zugriff auf diese Operationen.

Hängenbleiben im Status "Loading" nach dem Erstellen von VPC-Domains

Es kann vorkommen, dass der Configuration state (Konfigurationsstatus) einer neu erstellten Domain mit VPC-Zugriff dauerhaft Loading bleibt. Wenn dieses Problem auftritt, haben Sie wahrscheinlich AWS Security Token Service (AWS STS) für Ihre Region deaktiviert.

Um VPC-Endpoints zu Ihrer VPC hinzuzufügen, muss OpenSearch Service die Rolle übernehmen. AWSServiceRoleForAmazonOpenSearchService Daher AWS STS muss aktiviert sein, um neue Domänen zu erstellen, die VPC-Zugriff in einer bestimmten Region verwenden. Weitere Informationen zur Aktivierung und Deaktivierung AWS STS finden Sie im IAM-Benutzerhandbuch.

Abgelehnte Anfragen an die API OpenSearch

Mit der Einführung der tagbasierten Zugriffskontrolle für die OpenSearch API treten möglicherweise Fehler auf, bei denen der Zugriff verweigert wurde. Dies kann daran liegen, dass eine oder mehrere Ihrer Zugriffsrichtlinien Denyenthalten, der den Zustand ResourceTag verwendet, und diese Bedingungen jetzt eingehalten werden.

Beispielsweise die folgende Richtlinie zum Verweigern des Zugriffs auf die Aktion CreateDomain der Konfigurations-API, wenn die Domain das Tag environment=production hatte. Obwohl die Aktionsliste auch ESHttpPut enthält, traf die Verweigerungserklärung nicht für diese oder andere ESHttp*-Aktionen zu.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Action": [
      "es:CreateDomain",
      "es:ESHttpPut"
    ],
    "Effect": "Deny",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringEquals": {
        "aws:ResourceTag/environment": [
          "production"
        ]
      }
    }
  }]
}

Mit der zusätzlichen Unterstützung von Tags für OpenSearch HTTP-Methoden führt eine identitätsbasierte IAM-Richtlinie wie die oben beschriebene dazu, dass dem verbundenen Benutzer der Zugriff auf die Aktion verweigert wird. ESHttpPut Zuvor hätte der angehängte Benutzer in Ermangelung einer Tag-Validierung weiterhin PUT-Anfragen senden können.

Wenn Sie nach dem Aktualisieren Ihrer Domains auf die Service-Software R20220323 oder höher Fehler beim Zugriff feststellen, überprüfen Sie Ihre identitätsbasierten Zugriffsrichtlinien, um festzustellen, ob dies der Fall ist, und aktualisieren Sie sie gegebenenfalls, um den Zugriff zu ermöglichen.

Verbindung von Alpine Linux kann nicht hergestellt werden

Alpine Linux begrenzt die DNS-Antwortgröße auf 512 Byte. Wenn Sie versuchen, von Alpine Linux Version 3.18.0 oder niedriger aus eine Verbindung zu Ihrer OpenSearch Service-Domain herzustellen, kann die DNS-Auflösung fehlschlagen, wenn sich die Domain in einer VPC befindet und mehr als 20 Knoten hat. Wenn Sie eine Alpine Linux-Version verwenden, die höher als 3.18.0 ist, sollten Sie in der Lage sein, mehr als 20 Hosts aufzulösen. Weitere Informationen finden Sie in den Versionshinweisen zu Alpine Linux 3.18.0.

Wenn sich Ihre Domain in einer VPC befindet, empfehlen wir, andere Linux-Distributionen wie Debian, Ubuntu, CentOS, Red Hat Enterprise Linux oder Amazon Linux 2 zu verwenden, um eine Verbindung herzustellen.

Zu viele Anfragen für Search Backpressure

Bei der CPU-basierten Zugangskontrolle handelt es sich um einen Gatekeeping-Mechanismus, der die Anzahl der Anfragen an einen Knoten auf der Grundlage seiner aktuellen Kapazität proaktiv begrenzt, sowohl bei organischem Anstieg als auch bei Verkehrsspitzen. Übermäßige Anfragen geben bei Ablehnung den HTTP-Statuscode 429 „Zu viele Anfragen“ zurück. Dieser Fehler weist entweder auf unzureichende Clusterressourcen, ressourcenintensive Suchanfragen oder einen unbeabsichtigten Anstieg der Arbeitslast hin.

Der Such-Backpressure liefert den Grund für die Ablehnung, was bei der Feinabstimmung ressourcenintensiver Suchanfragen helfen kann. Bei Datenverkehrsspitzen empfehlen wir clientseitige Wiederholungen mit exponentiellem Backoff und Jitter.

Zertifikatsfehler bei der Verwendung von SDKs

Da AWS SDKs die CA-Zertifikate Ihres Computers verwenden, können Änderungen an den Zertifikaten auf den AWS Servern zu Verbindungsfehlern führen, wenn Sie versuchen, ein SDK zu verwenden. Fehlermeldungen variieren, enthalten aber in der Regel den folgenden Text:

Failed to query OpenSearch
...
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Sie können diese Fehler verhindern, indem Sie die CA-Zertifikate und das Betriebssystem up-to-date Ihres Computers beibehalten. Wenn dieses Problem in einer Unternehmensumgebung auftritt und Sie Ihren eigenen Computer nicht selbst verwalten, müssen Sie möglicherweise einen Administrator bitten, bei der Aktualisierung zu helfen.

Die folgende Liste zeigt die Mindestanforderungen an Betriebssystem- und Java-Versionen:

• Microsoft Windows-Versionen mit installierten Updates von Januar 2005 oder später enthalten mindestens eine der erforderlichen Zertifizierungsstellen in ihrer Trust-Liste.

• Mac OS X 10.4 mit Java für Mac OS X 10.4 Release 5 (Februar 2007), Mac OS X 10.5 (Oktober 2007) und spätere Versionen enthalten mindestens eine der erforderlichen Zertifizierungsstellen in ihrer Trust-Liste.

• Red Hat Enterprise Linux 5 (März 2007), 6 und 7 und CentOS 5, 6, und 7 enthalten alle mindestens eine der erforderlichen Zertifizierungsstellen in ihrer standardmäßigen CA-Trust-Liste.

• Java 1.4.2_12 (Mai 2006), 5 Update 2 (März 2005) und alle späteren Versionen, einschließlich Java 6 (Dezember 2006), 7 und 8, enthalten mindestens eine der erforderlichen Zertifizierungsstellen in ihrer standardmäßigen CA-Trust-Liste.

Die drei Zertifizierungsstellen sind:

• Amazon Root CA 1

• Starfield Services Root Certificate Authority – G2

• Starfield Class 2 Certification Authority

Stammzertifikate der ersten beiden Behörden sind bei Amazon Trust Services erhältlich, aber up-to-date es ist einfacher, Ihren Computer zu behalten. Weitere Informationen zu von ACM bereitgestellten Zertifikaten finden Sie unter AWS Certificate Manager – Häufig gestellte Fragen.

Anmerkung

Derzeit verwenden OpenSearch Dienstdomänen in der Region US-East-1 Zertifikate von einer anderen Behörde. Wir planen die Aktualisierung der Region zur Verwendung dieser neuen Zertifikatsstellen in naher Zukunft.