Behebung des roten Cluster-Status: Eine Schritt-für-Schritt-Anleitung zur Elasticsearch-Fehlerbehebung

Ein roter Elasticsearch-Cluster-Status bedeutet, dass mindestens ein primärer Shard nicht zugewiesen ist. Das ist der entscheidende Punkt. Einige Daten sind möglicherweise nicht verfügbar, Suchen gegen betroffene Indizes können teilweise oder fehlgeschlagene Ergebnisse liefern, und Schreibvorgänge auf diese Shards können nicht normal fortgesetzt werden.

Gelb ist anders: Primäre Shards sind zugewiesen, aber ein oder mehrere Replikate nicht. Gelb verdient dennoch Aufmerksamkeit, da Sie weniger Redundanz haben, aber Rot ist der Vorfall. Beginnen Sie nicht damit, Daten zu löschen oder Shards von Hand umzuleiten. Finden Sie zuerst heraus, welcher primäre Shard nicht zugewiesen ist und warum Elasticsearch sich weigert, ihn zuzuweisen.

Verstehen der Elasticsearch-Cluster-Gesundheit

Elasticsearch bietet eine Cluster Health API, die eine Momentaufnahme des Cluster-Status und der Shard-Zuweisung liefert. Diese API ist Ihr primäres Werkzeug zur Diagnose von Gesundheitsproblemen.

GET _cluster/health

Die Ausgabe dieses Befehls enthält ein status-Feld, das green, yellow oder red sein kann. Es liefert auch Informationen über die Anzahl der aktiven und nicht zugewiesenen Shards.

• Grün: Alle primären und Replikat-Shards sind zugewiesen und funktionieren korrekt.
• Gelb: Alle primären Shards sind zugewiesen, aber einige Replikat-Shards sind nicht zugewiesen.
• Rot: Ein oder mehrere primäre Shards sind nicht zugewiesen, was zu Datenunverfügbarkeit für diese Shards führt.

Verwenden Sie einen detaillierteren Gesundheitsaufruf, wenn Sie sich in einem Vorfall befinden:

GET _cluster/health?level=indices

Listen Sie dann die nicht zugewiesenen Shards auf:

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index

Häufige Ursachen und Schritte zur Fehlerbehebung für roten/gelben Status

Wenn Ihr Cluster nicht green ist, ist es Zeit zu untersuchen. Hier sind die häufigsten Gründe für nicht zugewiesene Shards und wie man sie behebt:

1. Unzureichender Speicherplatz

Elasticsearch hat Sicherheitsvorkehrungen, um Datenkorruption aufgrund voller Festplatten zu verhindern. Wenn einem Knoten der Speicherplatz ausgeht, verhindert er, dass neue Shards zugewiesen oder vorhandene wiederhergestellt werden.

Diagnose:

• Überprüfen Sie die Speichernutzung auf jedem Knoten.
• Verwenden Sie die Cluster Allocation Explain API, um zu verstehen, warum Shards nicht zugewiesen sind.

GET _cluster/allocation/explain

Diese API liefert detaillierte Begründungen, die oft auf Datenträger-Wasserzeichen hinweisen.

Lösung:

• Speicherplatz freigeben: Löschen Sie alte Indizes, verschieben Sie Daten auf eine andere Ebene oder fügen Sie Kapazität hinzu. Das Zusammenführen aktiver Indizes ist keine schnelle Lösung für Speicherplatz und kann während eines Vorfalls starke I/O verursachen.
• Mehr Speicherplatz hinzufügen: Erhöhen Sie die Speicherkapazität Ihrer Knoten.
• Datenträger-Wasserzeichen konfigurieren: Passen Sie cluster.routing.allocation.disk.watermark.low, high und flood_stage nur an, wenn die aktuellen Werte für Ihre Umgebung falsch sind. Das Anheben der Wasserzeichen kann Zeit verschaffen, aber es kann auch ein echtes Kapazitätsproblem verbergen.

2. Knoten hat den Cluster verlassen (Knotenentfernung)

Knoten können den Cluster aufgrund von Netzwerkproblemen, Abstürzen oder absichtlicher Entfernung verlassen. Wenn ein Knoten, der Shards (insbesondere primäre Shards) hält, den Cluster verlässt, werden diese Shards nicht zugewiesen.

Diagnose:

• Überprüfen Sie die Cluster-Protokolle auf Knoten, die kürzlich den Cluster verlassen haben.
• Überwachen Sie die Netzwerkkonnektivität zwischen Knoten.
• Stellen Sie sicher, dass alle Knoten füreinander auffindbar sind. Überprüfen Sie discovery.seed_hosts, Transportkonnektivität und Cluster-Protokolle. Führen Sie cluster.initial_master_nodes nicht als generische Lösung in einen bestehenden Cluster ein.

Lösung:

• Knoten neu starten: Wenn der Knoten abgestürzt oder nicht reagiert hat, versuchen Sie, ihn neu zu starten.
• Netzwerkprobleme beheben: Lösen Sie alle Netzwerkverbindungsprobleme zwischen Knoten.
• Knoten erneut hinzufügen: Wenn der Knoten absichtlich entfernt wurde, stellen Sie sicher, dass er korrekt konfiguriert ist, bevor er dem Cluster wieder beitritt.

3. Shard-Zuweisungsfilterung und -Bewusstsein

Fehlerhaft konfigurierte Shard-Zuweisungsregeln können verhindern, dass Shards verfügbaren Knoten zugewiesen werden.

Diagnose:

• Überprüfen Sie Ihre cluster.routing.allocation.*-Einstellungen, insbesondere cluster.routing.allocation.include, exclude und require-Filter.
• Überprüfen Sie cluster.routing.allocation.awareness.attributes, wenn Sie Zonen- oder Rack-Bewusstsein verwenden.

Lösung:

• Zuweisungsfilter anpassen: Ändern Sie die Filter, um Shards die Zuweisung zu den entsprechenden Knoten zu ermöglichen.
• Bewusstseinsattribute korrigieren: Stellen Sie sicher, dass Knoten korrekt mit Bewusstseinsattributen gekennzeichnet sind, falls verwendet, und dass Ihre Zuweisungsregeln diese respektieren.

4. Unzureichender Speicherplatz für die Zuweisung (nach Indexerstellung)

Selbst wenn eine Festplatte nicht voll ist, kann Elasticsearch die Shard-Zuweisung verhindern, wenn es vorhersagt, dass die Festplatte nach der Zuweisung die hohen Wasserzeichen überschreitet. Dies hängt mit den Datenträger-Wasserzeichen zusammen, betrifft aber speziell neue Zuweisungen.

Diagnose:

• Die _cluster/allocation/explain-API ist hier unverzichtbar.
• Überprüfen Sie den verfügbaren freien Speicherplatz im Vergleich zur erwarteten Größe der Shards.

Lösung:

• Ähnlich wie beim allgemeinen Speicherplatzproblem: Speicherplatz freigeben, mehr Speicher hinzufügen oder Wasserzeichen vorsichtig anpassen.

5. Shard-Größe und Knotenkapazität

Sehr große Shards oder eine große Anzahl von Shards können die Knotenressourcen (CPU, Speicher) belasten und die Zuweisung beeinträchtigen. Wenn ein Knoten sein Shard-Limit (cluster.routing.allocation.total_shards_per_node) erreicht hat, werden keine neuen Shards mehr zugewiesen.

Diagnose:

• Überprüfen Sie die Shard-Größen (GET _cat/shards?v).
• Überwachen Sie die Ressourcennutzung der Knoten (CPU, Speicher).
• Überprüfen Sie die Einstellung cluster.routing.allocation.total_shards_per_node.

Lösung:

• Shard-Druck reduzieren: Passen Sie für zukünftige Indizes Rollover und Shard-Anzahl an, sodass Shards in einem handhabbaren Größenbereich landen. Verwenden Sie für vorhandene Indizes Reindex, Shrink oder Split nur, nachdem der Cluster stabil genug ist, um die Arbeit zu bewältigen.
• Knotenkapazität erhöhen: Fügen Sie leistungsstärkere Knoten oder Knoten mit mehr Speicher/CPU hinzu.
• Shard-Limit anpassen: Erhöhen Sie bei Bedarf und ausreichenden Ressourcen cluster.routing.allocation.total_shards_per_node.

6. Master-Knoten-Probleme

Ein instabiler Master-Knoten kann zu Problemen bei der Shard-Zuweisung führen. Wenn der Master nicht verfügbar ist oder seine Aufgaben nicht erfüllen kann, können Shards nicht zugewiesen werden.

Diagnose:

• Überprüfen Sie die Cluster-Protokolle auf Master-bezogene Fehler oder Warnungen.
• Stellen Sie sicher, dass Sie eine ungerade Anzahl von Master-fähigen Knoten haben (normalerweise 3 oder 5), um Split-Brain-Szenarien zu vermeiden.
• Überprüfen Sie, ob Master-fähige Knoten einen Master wählen können.

Lösung:

• Master stabilisieren: Stellen Sie sicher, dass Master-fähige Knoten gesund sind, ausreichend Ressourcen haben und gut verbunden sind.
• Bootstrap-Verlauf überprüfen: cluster.initial_master_nodes ist nur für die erste Clusterbildung. Entfernen Sie es nach dem Bootstrap aus den Knotenkonfigurationen und beheben Sie Master-Instabilität durch Protokolle, Transportnetzwerke und Abstimmungskonfiguration.

Erweiterte Fehlerbehebung mit _cluster/allocation/explain

Die _cluster/allocation/explain-API ist Ihr leistungsstärkstes Werkzeug, um zu verstehen, warum ein bestimmter Shard nicht zugewiesen ist.

Beispiel:

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

Dies gibt eine detaillierte JSON-Ausgabe zurück, die erklärt, warum der primäre Shard 0 von my-index nicht zugewiesen werden kann. Suchen Sie nach Feldern wie deciders, die die Gründe für die Nichtzuweisung auflisten (z.B. DISK_THRESHOLD, NODE_LEFT, NO_VALID_SHARD_COPY).

Behebung des gelben Cluster-Status

Ein gelber Status bedeutet, dass primäre Shards zugewiesen sind, aber Replikate nicht. Dies betrifft hauptsächlich die Datenredundanz und Fehlertoleranz.

Häufige Ursachen:

• Unzureichende Knoten: Sie haben nicht genügend Knoten, um die erforderliche Anzahl von Replikaten für Ihre Indizes aufzunehmen.
• Shard-Zuweisungsfilterung: Ähnlich wie beim roten Status können Filter verhindern, dass Replikate zugewiesen werden.
• Speicherplatzbeschränkungen: Knoten haben möglicherweise genügend Speicherplatz für primäre Shards, aber nicht für Replikate, insbesondere wenn Datenträger-Wasserzeichen aktiv sind.

Lösung:

• Mehr Knoten hinzufügen: Erhöhen Sie die Anzahl der Knoten in Ihrem Cluster.
• Replikatanzahl anpassen: Reduzieren Sie die Anzahl der Replikate pro Index (index.number_of_replicas), wenn Fehlertoleranz nicht für alle Indizes kritisch ist.
• Zuweisungseinstellungen überprüfen: Stellen Sie sicher, dass Replikat-Shards den verfügbaren Knoten zugewiesen werden dürfen.

Best Practices zur Aufrechterhaltung der Cluster-Gesundheit

• Speichernutzung überwachen: Überwachen Sie proaktiv den Speicherplatz auf allen Knoten und richten Sie Warnungen ein.
• Cluster richtig dimensionieren: Stellen Sie sicher, dass Sie genügend Knoten und Ressourcen für Ihr Datenvolumen und Ihre Abfragelast haben.
• Shard-Verwaltung: Halten Sie Shard-Größen innerhalb empfohlener Bereiche und vermeiden Sie übermäßige Sharding.
• Cluster-Gesundheit regelmäßig überprüfen: Verwenden Sie GET _cluster/health und GET _cluster/allocation/explain als Teil Ihrer Routineüberwachung.
• Änderungen testen: Bevor Sie wesentliche Änderungen an Zuweisungseinstellungen oder Datenträger-Wasserzeichen vornehmen, testen Sie diese in einer Staging-Umgebung.

Sobald Sie den Zuweisungsentscheider kennen, ist der Weg normalerweise klar. Datenträgerschwelle bedeutet Kapazität. NODE_LEFT bedeutet, den fehlenden Knoten wiederherzustellen oder zu ersetzen. NO_VALID_SHARD_COPY bedeutet, dass Sie möglicherweise eine Snapshot-Wiederherstellung oder eine bewusste Datenverlustentscheidung unter Verwendung der dokumentierten unsicheren Wiederherstellungsverfahren von Elasticsearch benötigen. Dieser letzte Fall sollte langsam behandelt werden, zuerst mit Überprüfung der Backups, da der Befehl, der den Cluster aus dem roten Status bringt, auch den permanenten Verlust der neuesten Daten des fehlenden primären Shards bestätigen kann.