Fehlerbehebung bei der Elasticsearch-Cluster-Gesundheit: Eine Schritt-für-Schritt-Anleitung

Behebung von Problemen mit der Elasticsearch-Cluster-Integrität: Eine Schritt-für-Schritt-Anleitung

Elasticsearch ist ein robustes verteiltes System, das jedoch, wie jede verteilte Architektur, eine aktive Überwachung und gelegentliche Eingriffe erfordert, um eine optimale Integrität zu gewährleisten. Der Cluster-Integritätsstatus ist die wichtigste Kennzahl zur Bestimmung der Betriebsbereitschaft und der Datensicherheit Ihrer Bereitstellung. Wenn der Cluster von Grün zu Gelb oder, was kritisch ist, zu Rot wechselt, sind die Datenintegrität oder die Verfügbarkeit gefährdet.

Diese umfassende Anleitung bietet fachkundige Schritte zur Diagnose und Behebung gängiger Probleme mit der Elasticsearch-Cluster-Integrität, wobei der Schwerpunkt insbesondere auf der Wiederherstellung des Status Gelb und Rot liegt. Wir werden praktische Cat APIs und schrittweise Überprüfungen verwenden, um die Grundursache schnell zu identifizieren und Korrekturmaßnahmen zu ergreifen.

1. Verständnis des Elasticsearch-Cluster-Integritätsstatus

Bevor Sie mit der Fehlerbehebung beginnen, ist es wichtig zu verstehen, was jede Farbe des Cluster-Integritätsstatus bedeutet. Der Integritätsstatus wird durch den Zuteilungszustand Ihrer primären und Replikat-Shards über die Cluster-Knoten hinweg bestimmt.

Status	Bedeutung	Implikationen
Grün	Alle primären und Replikat-Shards sind erfolgreich zugewiesen.	Der Cluster ist voll funktionsfähig und ausfallsicher.
Gelb	Alle primären Shards sind zugewiesen, aber eines oder mehrere Replikat-Shards sind nicht zugewiesen (`unassigned`).	Daten sind verfügbar, aber dem Cluster fehlt die volle Ausfallsicherheit gegenüber Knotenausfällen.
Rot	Mindestens ein primärer Shard ist nicht zugewiesen (und somit nicht verfügbar).	Datenverlust oder Unzugänglichkeit für den Index, der die fehlerhaften Shard(s) enthält. Kritisches Handeln erforderlich.

2. Erste Diagnose: Überprüfung der Cluster-Integrität

Der erste Schritt bei jedem Fehlerbehebungsprozess ist die Bestätigung des aktuellen Status und die Erfassung grundlegender Metriken mithilfe der Cluster Health API und der Nodes API.

Schritt 2.1: Cluster-Integrität überprüfen

Verwenden Sie die _cat/health-API, um eine Zusammenfassung auf hoher Ebene zu erhalten. Der Parameter ?v liefert eine ausführliche Ausgabe, einschließlich der Anzahl der Knoten und der Gesamtzahl der Shards.

GET /_cat/health?v

Beispielausgabe (Status Gelb):

epoch      timestamp cluster       status node.total node.data shards  pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1678233600 09:00:00  my-cluster    yellow 3          3         10     5    0    0        5 0             -                  50.0%

Wenn der Status Gelb oder Rot ist, notieren Sie den Wert unter unassign.

Schritt 2.2: Knotenstatus und Arbeitsspeicher überprüfen

Stellen Sie sicher, dass alle erwarteten Knoten verbunden sind und ordnungsgemäß funktionieren. Überprüfen Sie außerdem die Heap-Auslastung (entscheidend für Leistung und Stabilität).

GET /_cat/nodes?v&h=name,node.role,version,heap.percent,disk.total,disk.used,disk.avail

Wenn ein Knoten in dieser Liste fehlt, liegt möglicherweise ein Konnektivitätsproblem oder ein gestoppter Dienst vor.

3. Behebung des Roten Cluster-Status (Ausfall des primären Shards)

Der Status Rot bedeutet, dass Daten sofort unzugänglich sind. Das Ziel ist es, den primären Shard so schnell wie möglich wieder online zu bringen.

Schritt 3.1: Identifizieren der nicht zugewiesenen primären Shards

Verwenden Sie die _cat/shards-API, um den genauen Index und Shard zu lokalisieren, der das Problem verursacht. Suchen Sie gezielt nach Einträgen, die als UNASSIGNED mit der Rolle p (primär) gekennzeichnet sind.

GET /_cat/shards?v | grep UNASSIGNED

Beispielausgabe:

index_logs 0 p UNASSIGNED

Schritt 3.2: Überprüfung der Zuteilungserklärung

Dies ist der wichtigste einzelne Diagnoseschritt. Die Allocation Explain API teilt Ihnen mit, warum ein bestimmter Shard (oder ein beliebiger nicht zugewiesener Shard) nicht zugewiesen werden kann.

GET /_cluster/allocation/explain

Häufige Gründe für den Roten Status:

Knotenausfall: Der Knoten, der den primären Shard enthielt, ist abgestürzt oder aus dem Cluster entfernt worden. Wenn der ausgefallene Knoten ausreichende Replikate auf anderen Knoten hat, sollte der primäre Shard automatisch ein Replikat hochstufen. Wenn alle Kopien (primär und Replikate) auf dem ausgefallenen Knoten befanden, ist der Shard verloren, es sei denn, der Knoten wird wiederhergestellt.
Beschädigte Daten: Die primären Shard-Dateien auf der Festplatte sind beschädigt, was den Knoten daran hindert, sie zu initialisieren.

Schritt 3.3: Aktionsplan für den Roten Status

Szenario A: Knoten offline (Bevorzugt)
- Wenn der Knoten, der den primären Shard enthielt, lediglich offline ist, stellen Sie den Knotendienst wieder her (z. B. starten Sie Elasticsearch neu oder beheben Sie Netzwerkprobleme). Sobald der Knoten dem Cluster wieder beitritt, sollte sich der primäre Shard erholen.
Szenario B: Primärer Shard verloren (Letzter Ausweg)
- Wenn der Knoten dauerhaft verloren ist und keine Replikate existierten, sind die Daten weg. Sie müssen die Wiederherstellung manuell mit dem Befehl allocate_empty_primary überspringen. Warnung: Dadurch wird ein völlig neuer, leerer primärer Shard erstellt, was zu einem dauerhaften Datenverlust für dieses Segment des Index führt.

POST /_cluster/reroute
{
  "commands" : [
    {
      "allocate_empty_primary" : {
        "index" : "[index-name]", 
        "shard" : [shard-id],
        "node" : "[target-node-name]", 
        "accept_data_loss" : true
      }
    }
  ]
}

Best Practice: Bevor Sie auf allocate_empty_primary zurückgreifen, überprüfen Sie immer, ob kein Snapshot oder Backup für den Index existiert.

4. Behebung des Gelben Cluster-Status (Ausfall des Replikat-Shards)

Der Status Gelb bedeutet, dass der Cluster betriebsbereit, aber anfällig ist. Das Hauptziel ist die Zuweisung der fehlenden Replikate.

Schritt 4.1: Verwenden der Allocation Explain API

Wenn der Status Gelb ist, verwenden Sie die _cluster/allocation/explain-API (Abschnitt 3.2), um zu verstehen, warum das Replikat nicht zugewiesen werden kann. Die Erklärung für Replikate ist typischerweise einfacher.

Häufige Gründe für den Gelben Status:

Grundcode	Erklärung	Lösung
`NO_AVAILABLE_NODES`	Clustergröße ist zu klein (z. B. Replikatanzahl ist 2, aber es existieren nur 2 Knoten).	Fügen Sie weitere Datenknoten hinzu oder reduzieren Sie `number_of_replicas`.
`NOT_ENOUGH_DISK_SPACE`	Knoten haben den niedrigen oder hohen Wasserzeichenschwellenwert erreicht.	Löschen Sie alte Indizes, geben Sie Speicherplatz frei oder passen Sie die Disk-Wasserzeichen an.
`ALLOCATION_DISABLED`	Die Shard-Zuteilung wurde explizit durch Cluster-Einstellungen deaktiviert.	Aktivieren Sie das Routing mit `PUT /_cluster/settings` erneut.
`PRIMARY_NOT_ACTIVE`	Der primäre Shard wird noch initialisiert oder wiederhergestellt.	Warten Sie, bis der primäre Shard aktiv wird (Grün).

Schritt 4.2: Überprüfung der Knoten-Anforderungen und -Einschränkungen

Stellen Sie sicher, dass der Cluster die grundlegenden Anforderungen für die Replikat-Zuweisung erfüllt:

Knotenanzahl: Für N Replikate benötigen Sie mindestens N+1 Datenknoten, um sicherzustellen, dass sich primäre und Replikate niemals auf demselben Knoten befinden.
Disk-Wasserzeichen: Elasticsearch stoppt die Zuweisung von Shards zu Knoten, wenn die Festplattennutzung das hohe Wasserzeichen (Standard 90 %) überschreitet.

# Einstellungen für die Festplattenzuteilung überprüfen
GET /_cluster/settings?flat_settings=true&filter_path=*watermark*

# Beispiel: Festlegen des hohen Wasserzeichens auf 95 % (Vorübergehend!)
PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.high": "95%"
  }
}

Schritt 4.3: Manuelles Rerouting (Falls die Zuteilungslogik fehlschlägt)

In seltenen Fällen, wenn der Standardzuteilungsprozess trotz ausreichender Ressourcen festzustecken scheint, können Sie die Zuweisung des Replikats zu einem bestimmten fehlerfreien Knoten mithilfe des Befehls allocate_replica manuell erzwingen.

POST /_cluster/reroute
{
  "commands" : [
    {
      "allocate_replica" : {
        "index" : "[index-name]", 
        "shard" : [shard-id],
        "node" : "[target-node-name]"
      }
    }
  ]
}

5. Erweiterte Fehlerbehebung und häufige Fallstricke

Wenn der Status Rot oder Gelb weiterhin besteht, liegt die Grundursache möglicherweise außerhalb der standardmäßigen Shard-Zuteilungslogik.

5.1 Netzwerkkonnektivität und Split-Brain

In verteilten Systemen kann die Partitionierung (Split-Brain) schwerwiegende Probleme verursachen. Wenn Master-fähige Knoten nicht kommunizieren können, kann der Cluster möglicherweise keinen stabilen Master wählen, was zu nicht zugewiesenen Shards führt.

Aktion: Überprüfen Sie die Netzwerkkonnektivität zwischen allen Knoten, insbesondere zwischen Master-fähigen Knoten.
Konfigurationsprüfung: Stellen Sie sicher, dass Ihre Liste discovery.seed_hosts korrekt ist und dass die Einstellung cluster.initial_master_nodes während des Cluster-Bootstraps richtig verwendet wurde.

5.2 Hoher JVM-Speicherdruck

Eine übermäßige Heap-Nutzung (oft über 75 %) führt zu häufigen, langen Garbage Collection (GC)-Pausen. Während dieser Pausen kann ein Knoten nicht mehr reagieren, was dazu führt, dass der Master-Knoten ihn verwirft und nicht zugewiesene Shards entstehen.

Aktion: Überwachen Sie die Heap-Nutzung (_cat/nodes?h=heap.percent). Wenn diese dauerhaft hoch ist, sollten Sie den Knotenspeicher erhöhen, Indexierungsprozesse optimieren oder Index Lifecycle Management (ILM) implementieren.

5.3 Shard-Zuteilungsfilterung

Die versehentliche Anwendung von Zuteilungsfiltern (mithilfe von Knotenattributen wie Tags oder IDs) kann verhindern, dass Shards Knoten zugewiesen werden, die andernfalls berechtigt wären.

# Überprüfen Sie die Zuteilungsregeln auf Indexebene
GET /[index-name]/_settings
# Suchen Sie nach: index.routing.allocation.require.*

# Index-Zuteilungsregeln zurücksetzen (falls erforderlich)
PUT /[index-name]/_settings
{
  "index.routing.allocation.require": null
}

Zusammenfassende Checkliste für die schnelle Wiederherstellung

Status	Primäres Diagnosetool	Wichtige Aktionsschritte
Gelb	`GET /_cluster/allocation/explain`	1. Festplattenspeicher prüfen. 2. Knotenanzahl vs. Replikatanzahl überprüfen. 3. Nach Zuteilungsfilterungsregeln suchen. 4. Auf primäre Wiederherstellung warten.
Rot	`GET /_cat/shards?v \| grep UNASSIGNED`	1. Protokolle auf dem zuvor hostenden Knoten prüfen. 2. Versuchen Sie, den ausgefallenen Knoten neu zu starten. 3. Wenn der primäre Shard als verloren bestätigt wird und kein Backup existiert, verwenden Sie `allocate_empty_primary` (Risiko des Datenverlusts).

Durch die systematische Nutzung der _cat-APIs und des kritischen Endpunkts _cluster/allocation/explain können Sie die Ursache der Verschlechterung der Cluster-Integrität schnell identifizieren und die notwendigen Korrekturschritte implementieren, um Ihren Cluster wieder in den stabilen Status Grün zu versetzen.