Fehlerbehebung bei häufigen Elasticsearch-Shard-Allokationsfehlern
Lernen Sie, häufige Elasticsearch-Shard-Allokationsfehler zu identifizieren und zu beheben. Dieser Leitfaden behandelt das Erkennen nicht zugewiesener Shards, die Diagnose von Problemen wie Speicherplatzfehlern, Knotenunverfügbarkeit und Allokationsfilterung und bietet umsetzbare Lösungen sowie Best Practices für die Aufrechterhaltung eines gesunden Elasticsearch-Clusters.
Fehlerbehebung bei häufigen Elasticsearch-Shard-Allokationsfehlern
Shard-Allokationsfehler sind der Punkt, an dem Elasticsearch aufhört, abstrakt zu sein. Die Cluster-Health wird gelb oder rot, Suchen liefern nur partielle Ergebnisse, die Indizierung verlangsamt sich, und das Team muss herausfinden, ob das Problem an der Festplatte, einem fehlenden Knoten, einer fehlerhaften Allokationsregel oder beschädigten Shard-Daten liegt.
Der Fehler, den ich am häufigsten sehe, ist, jeden nicht zugewiesenen Shard gleich zu behandeln. Ein Replica-Shard, der nach einem geplanten Neustart verzögert ist, ist nicht derselbe Notfall wie ein nicht zugewiesener Primary-Shard für den Haupt-Orders-Index. Beginnen Sie damit, herauszufinden, welcher Shard nicht zugewiesen ist, ob es sich um einen Primary oder Replica handelt und was Elasticsearch über die Allokationsentscheidung sagt.
Das Health-Signal richtig lesen
Beginnen Sie mit der Cluster-Health:
GET /_cluster/health?pretty
Die wichtigen Felder sind status, active_primary_shards, active_shards, relocating_shards, initializing_shards, unassigned_shards und delayed_unassigned_shards.
Gelb bedeutet, dass alle Primary-Shards zugewiesen sind, aber ein oder mehrere Replicas nicht. Ihre Daten sollten noch verfügbar sein, aber die Redundanz ist reduziert.
Rot bedeutet, dass ein oder mehrere Primary-Shards nicht zugewiesen sind. Daten in diesen Shards sind nicht verfügbar, es sei denn, Elasticsearch kann ein Replica promoten, den Knoten mit dem Shard wiederherstellen oder aus einem Snapshot wiederherstellen.
Wenn relocating_shards oder initializing_shards ungleich Null ist, heilt sich der Cluster möglicherweise bereits. Unterbrechen Sie keine normale Wiederherstellung, nur weil die Farbe vorübergehend gelb ist.
Die nicht zugewiesenen Shards auflisten
Verwenden Sie _cat/shards, um das genaue Problem zu sehen:
GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason&s=state,index
Suchen Sie nach UNASSIGNED. Die Spalte prirep zeigt Ihnen, ob der Shard ein Primary (p) oder ein Replica (r) ist. Die Spalte unassigned.reason gibt einen kurzen Grund wie NODE_LEFT, INDEX_CREATED, CLUSTER_RECOVERED oder ALLOCATION_FAILED an.
Für einen großen Cluster eingrenzen:
GET /_cat/shards/logs-*?v&h=index,shard,prirep,state,node,unassigned.reason
Sobald Sie den Index, die Shard-Nummer und das Primary/Replica-Flag haben, fragen Sie Elasticsearch nach der tatsächlichen Erklärung.
Die Allocation Explain API verwenden
Für jeden aktuell nicht zugewiesenen Shard:
GET /_cluster/allocation/explain
{}
Für einen bestimmten Shard:
GET /_cluster/allocation/explain
{
"index": "logs-2026.05.24",
"shard": 0,
"primary": false
}
Lesen Sie can_allocate, allocate_explanation, unassigned_info und node_allocation_decisions. Die Knotenentscheidungen sind besonders nützlich, da sie zeigen, warum jeder Knoten abgelehnt wurde. Häufige Entscheider sind Disk-Schwellenwerte, Same-Shard-Regeln, Allokationsfilter, Awareness-Regeln und Total-Shards-per-Node-Limits.
Wenn die Ausgabe no_valid_shard_copy für einen Primary anzeigt, behandeln Sie dies ernst. Elasticsearch sieht derzeit keine verwendbare Kopie dieses Primary-Shards.
Ursache 1: Nicht genügend geeignete Knoten
Ein einfacher Single-Node-Cluster mit einem Replica wird für immer gelb sein. Elasticsearch wird kein Replica auf denselben Knoten wie seinen Primary legen. Ein Drei-Node-Cluster mit einem Index, der für zwei Replicas konfiguriert ist, benötigt drei geeignete Datenknoten. Wenn Allokations-Awareness besagt, dass Kopien über Zonen verteilt werden müssen, benötigen Sie auch genügend Knoten in den erforderlichen Zonen.
Überprüfen Sie die Replica-Einstellungen:
GET /my-index/_settings?filter_path=*.settings.index.number_of_replicas
Wenn dies eine Labor- oder temporäre Umgebung ist, reduzieren Sie die Replicas:
PUT /my-index/_settings
{
"index": {
"number_of_replicas": 0
}
}
Für die Produktion ist die bessere Antwort normalerweise, geeignete Datenknoten hinzuzufügen oder eine unrealistische Replica-Anzahl anzupassen. Das Verringern der Replicas entfernt Redundanz.
Ursache 2: Disk-Watermarks
Speicherplatzdruck ist einer der häufigsten Allokationsblocker. Elasticsearch verwendet Disk-Watermarks, um das Füllen von Knoten zu vermeiden. Wenn Knoten Schwellenwerte überschreiten, kann Elasticsearch aufhören, Shards zuzuweisen, und Shards wegbewegen.
Überprüfen Sie Allokation und Speichernutzung:
GET /_cat/allocation?v
GET /_cat/nodes?v&h=name,ip,disk.used_percent,disk.avail,heap.percent,ram.percent,node.role
Die Allocation-Explain-Ausgabe kann anzeigen, dass ein Knoten über dem niedrigen oder hohen Disk-Watermark liegt. Wenn ein Index Flood-Stage-Bedingungen erreicht hat, kann Elasticsearch auch einen Schreibblock auf betroffene Indizes setzen.
Gute Lösungen sind Kapazitätslösungen: Löschen Sie alte Indizes nach Bestätigung der Snapshots, fügen Sie Speicherplatz hinzu, fügen Sie Datenknoten hinzu, verschieben Sie Daten in eine andere Stufe oder verkürzen Sie die Aufbewahrungsdauer durch Index Lifecycle Management.
Das Ändern von Watermarks kann in einem kontrollierten Notfall vernünftig sein, ist aber kein Kapazitätsplan. Wenn jeder Datenknoten fast voll ist, bringt das Erhöhen der Schwellenwerte den Cluster nur näher an den Ausfall.
Nachdem Sie Speicherplatz von einem Flood-Stage-Ereignis freigegeben haben, überprüfen Sie auf einen Read-Only-Block:
GET /my-index/_settings?filter_path=*.settings.index.blocks.write,*.settings.index.blocks.read_only_allow_delete
Entfernen Sie den Block erst, nachdem der Speicherplatzdruck behoben ist:
PUT /my-index/_settings
{
"index.blocks.read_only_allow_delete": null
}
Ursache 3: Allokation nach Wartungsarbeiten deaktiviert
Teams deaktivieren oft die Allokation während rollierender Wartungsarbeiten und vergessen dann, sie wieder zu aktivieren.
Überprüfen Sie die Cluster-Einstellungen:
GET /_cluster/settings?include_defaults=true&pretty
Suchen Sie nach cluster.routing.allocation.enable. Werte umfassen all, primaries, new_primaries und none. Wenn es none ist, werden Replicas und möglicherweise andere Shard-Bewegungen nicht normal allokiert.
Allokation wieder aktivieren:
PUT /_cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}
Überprüfen Sie auch transient-Einstellungen. Eine vorübergehende Wartungseinstellung kann den Cluster immer noch beeinflussen, selbst wenn der persistente Abschnitt in Ordnung aussieht.
Ursache 4: Restriktive Allokationsfilter
Index-Level-Filter können einen Index auf bestimmte Knoten festlegen:
GET /my-index/_settings?filter_path=*.settings.index.routing.allocation.*
Cluster-Level-Filter können Knoten von der Allokation ausschließen:
GET /_cluster/settings?include_defaults=true&filter_path=**.cluster.routing.allocation.*
Knotenattribute sind ebenfalls wichtig:
GET /_cat/nodeattrs?v
Ein typischer Fehler sieht so aus: Ein Index erfordert box_type: hot, aber die Hot-Knoten wurden ersetzt und die neuen Knoten haben nicht node.attr.box_type: hot. Elasticsearch befolgt die Regel genau; die Regel ist jetzt falsch.
Um übermäßig restriktive Index-Filter zu entfernen:
PUT /my-index/_settings
{
"index.routing.allocation.require.box_type": null,
"index.routing.allocation.include.box_type": null,
"index.routing.allocation.exclude.box_type": null
}
Verwenden Sie die genauen Einstellungsnamen, die in Ihrem Index vorhanden sind. Löschen Sie Allokationsregeln nicht blind, wenn sie echte Zonen- oder Stufenanforderungen codieren.
Ursache 5: Verzögerte Allokation nachdem ein Knoten den Cluster verlassen hat
Wenn ein Knoten den Cluster verlässt, kann Elasticsearch die Allokation von Replica-Shards verzögern, weil der Knoten möglicherweise schnell zurückkommt. Dies vermeidet das Kopieren großer Shards über das Netzwerk während eines normalen Neustarts.
Überprüfen Sie verzögerte Shards:
GET /_cluster/health?pretty
Wenn delayed_unassigned_shards größer als Null ist und der Knoten voraussichtlich zurückkommt, kann Warten die beste Aktion sein. Sie können auch die Index-Einstellungen überprüfen:
GET /my-index/_settings?filter_path=*.settings.index.unassigned.node_left.delayed_timeout
Der Standardwert ist normalerweise eine Minute, aber überprüfen Sie immer Ihren Cluster und Ihre Version. Einige Teams erhöhen ihn für geplante rollierende Neustarts großer Shards. Machen Sie ihn nicht so lang, dass echte Fehler Replicas für eine unangenehme Zeit vermissen lassen.
Ursache 6: Zu viele Shards auf einem Knoten
index.routing.allocation.total_shards_per_node kann begrenzen, wie viele Shards eines Index auf demselben Knoten leben dürfen. Cluster-Level-Shard-Limits können ebenfalls gelten. Diese Einstellungen sind nützlich, können aber die Allokation in kleinen Clustern blockieren.
Überprüfen Sie die Index-Einstellungen:
GET /my-index/_settings?filter_path=*.settings.index.routing.allocation.total_shards_per_node
Wenn Sie fünf Primary-Shards, ein Replica, zwei Datenknoten und ein niedriges Limit pro Knoten haben, hat Elasticsearch möglicherweise keine zulässige Platzierung. Beheben Sie das Limit, fügen Sie Knoten hinzu oder gestalten Sie die Shard-Anzahl neu.
Ursache 7: Keine gültige Kopie eines Primary
Dies ist der beängstigende Fall. Allocation Explain kann melden, dass es keine gültige Shard-Kopie für einen Primary gibt. Vielleicht ist der einzige Knoten mit dem Primary weg. Vielleicht ist die Festplatte ausgefallen. Vielleicht sind Shard-Daten beschädigt.
Versuchen Sie zunächst, den fehlenden Knoten wiederherzustellen, wenn er voraussichtlich zurückkommt. Überprüfen Sie Systemlogs, Elasticsearch-Logs, Festplattenzustand und Netzwerkkonnektivität. Wenn ein gültiges Replica existiert, sollte Elasticsearch es normalerweise promoten.
Wenn keine gültige Kopie existiert, stellen Sie aus einem Snapshot wieder her:
POST /_snapshot/my_repository/snapshot_name/_restore
{
"indices": "affected-index"
}
Wenn die Daten aus einem Quellsystem neu aufgebaut werden können und Sie den Verlust der Shard-Inhalte akzeptieren, ist allocate_empty_primary verfügbar, aber es ist ein Datenverlust-Vorgang:
POST /_cluster/reroute
{
"commands": [
{
"allocate_empty_primary": {
"index": "affected-index",
"shard": 0,
"node": "target-node",
"accept_data_loss": true
}
}
]
}
Verwenden Sie dies nicht, um "den Cluster grün zu machen", es sei denn, Sie haben bewusst entschieden, dass die fehlenden Daten weg oder wiederherstellbar sind.
Wiederherstellung beobachten
Nach einer Änderung den Fortschritt beobachten:
GET /_cat/recovery?v&active_only=true
GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason
GET /_cluster/health?pretty
Große Shards brauchen Zeit. Wenn Byte-Zahlen in _cat/recovery sich bewegen, arbeitet der Cluster. Wenn sich nichts ändert, überprüfen Sie erneut Allocation Explain. Die Entscheidung von Elasticsearch hat sich möglicherweise nach Ihrer ersten Korrektur geändert und zeigt den nächsten Blocker.
Prävention, die tatsächlich hilft
Überwachen Sie die Festplatte, bevor Watermarks erreicht werden. Alarmieren Sie auf Trends, nicht nur auf volle Festplatten.
Verwenden Sie ILM oder Data Streams für Logs und Metriken, damit die Aufbewahrung automatisch erfolgt.
Halten Sie Snapshots aktuell und testen Sie Wiederherstellungen. Ein Snapshot, den Sie noch nie wiederhergestellt haben, ist nur eine Hoffnung.
Halten Sie Shard-Größen und Shard-Anzahlen angemessen. Zu viele winzige Shards machen Allokation und Wiederherstellung langsamer, als das Datenvolumen vermuten lässt.
Dokumentieren Sie Allokationsfilter und Knotenattribute. Sechs Monate später wird jemand einen Knoten ersetzen und das Attribut vergessen, das einen Index allokierbar gemacht hat.
Behandeln Sie Gelb als Warnung und Rot als Vorfall. Gelb kann während Wartungsarbeiten akzeptabel sein, sollte aber nicht zum Hintergrundrauschen werden. Rot bedeutet, dass mindestens ein Primary-Shard nicht verfügbar ist, und je länger Sie warten, desto weniger einfache Wiederherstellungsoptionen haben Sie möglicherweise.
Eine Feld-Checkliste für Vorfälle
Wenn die Shard-Allokation ausfällt, sammeln Sie jedes Mal die gleichen Beweise. Es verhindert, dass das Team zwischen Theorien hin- und herspringt.
Führen Sie aus:
GET /_cluster/health?pretty
GET /_cat/nodes?v&h=name,ip,roles,master,disk.used_percent,heap.percent,ram.percent
GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason&s=state,index
GET /_cat/allocation?v
GET /_cat/recovery?v&active_only=true
GET /_cluster/settings?include_defaults=true&pretty
Führen Sie dann Allocation Explain für einen repräsentativen nicht zugewiesenen Shard aus. Wenn es viele gibt, gruppieren Sie sie nach Grund. Zehn nicht zugewiesene Replicas, die durch Disk-Watermarks blockiert sind, sind ein Problem. Drei Primaries mit no_valid_shard_copy sind ein anderes Problem.
Notieren Sie, ob die betroffenen Daten neu aufgebaut werden können. Logs aus einer vorgelagerten Warteschlange, Metriken von Agenten und abgeleitete Suchindizes können aus Quellsystemen wiederhergestellt werden. Benutzererstellte Inhalte oder Compliance-Aufzeichnungen möglicherweise nicht. Wiederherstellungsbefehle sollten dieser geschäftlichen Realität folgen.
Wann warten und wann handeln
Warten Sie, wenn die Wiederherstellung aktiv fortschreitet, der fehlende Knoten voraussichtlich bald zurückkommt oder die verzögerte Allokation genau das tut, wofür Sie sie konfiguriert haben. Sie können den Fortschritt mit _cat/recovery überprüfen; sich bewegende Byte-Zahlen und Dateizahlen sind gute Zeichen.
Handeln Sie, wenn Allocation Explain einen permanenten Blocker zeigt: keine geeigneten Knoten, Disk-Watermarks auf jedem Knoten, Allokation deaktiviert, fehlende Knotenattribute oder keine gültige Shard-Kopie. Warten wird eine Regel, die jeden Knoten ablehnt, nicht beheben.
Eskalieren Sie schnell, wenn Primary-Shards für wichtige Indizes nicht zugewiesen sind. Replica-Fehler reduzieren die Sicherheit. Primary-Fehler reduzieren die Verfügbarkeit.
Vermeiden Sie, die Wiederherstellung zu verlangsamen
Große Wiederherstellungen konkurrieren mit normaler Suche und Indizierung. Das gleichzeitige Hinzufügen zu vieler Knoten, das Neustarten weiterer Knoten oder das Erhöhen der Wiederherstellungskonkurrenz ohne Überprüfung der Festplatten- und Netzwerkkapazität kann den Cluster instabiler machen.
Wenn Sie Wiederherstellungseinstellungen anpassen, tun Sie dies bewusst und notieren Sie die ursprünglichen Werte. Einstellungen wie gleichzeitige Wiederherstellungen können in einigen Umgebungen helfen und in anderen schaden. Eine schnellere Wiederherstellung auf dem Papier kann Festplatten überlasten und die Abfragelatenz so weit erhöhen, dass Benutzer einen schlimmeren Ausfall erleben.
Behalten Sie heiße Knoten im Auge. Die Allokation kann technisch erfolgreich sein, während zu viel Arbeit auf einen Knoten gelegt wird, aufgrund von Shard-Größen, Stufenregeln oder ungleicher Festplattennutzung. Verwenden Sie _cat/allocation, Knotenstatistiken und Ihr Überwachungssystem, um zu bestätigen, dass der Cluster nach dem unmittelbaren Fehler ausgeglichen ist.
Nachbereitungsmaßnahmen
Die meisten Shard-Allokationsvorfälle haben eine Präventionsgeschichte. Disk-Watermark-Vorfälle weisen auf Aufbewahrung, ILM oder Kapazitätsplanung hin. Allokationsfilter-Vorfälle weisen auf fehlende Runbook-Dokumentation hin. No-Valid-Copy-Vorfälle weisen auf Snapshots und Upstream-Wiedergabe hin. Langsame Wiederherstellung weist auf Shard-Größen und Hardware hin.
Schließen Sie den Vorfall nicht einfach, weil die Health grün ist. Entfernen Sie temporäre Replica-Änderungen, stellen Sie normale Aktualisierungsintervalle wieder her, aktivieren Sie die Allokation, wenn sie geändert wurde, überprüfen Sie Snapshots und fügen Sie den Alarm hinzu, der das Problem früher erkannt hätte.
Sonderfall: Geschlossene und versteckte Indizes
Manchmal allokiert ein Index nicht, weil er geschlossen, versteckt oder Teil einer Systemfunktion ist, von der Sie nicht wussten, dass Sie sie berühren. Seien Sie vorsichtig mit breiten Wildcard-Befehlen, wenn Systemindizes vorhanden sind. In modernen Clustern können Sicherheits-, Kibana-, Transform- und andere Stack-Funktionen ihre eigenen Indizes verwalten.
Verwenden Sie enge Muster und schließen Sie versteckte Indizes nur ein, wenn Sie sie überprüfen möchten. Wenn ein Systemindex Allokationsprobleme hat, überprüfen Sie die zugehörigen Stack-Komponentenlogs sowie Elasticsearch. Zum Beispiel kann ein Problem mit einem Kibana-Saved-Object-Index als Elasticsearch-Shard-Allokationsproblem und als Kibana-Startfehler auftreten.
Die Regel ist dieselbe wie bei Benutzerdaten: Identifizieren Sie den genauen Index, verstehen Sie, wem er gehört, und wählen Sie dann die Korrektur. Löschen oder forcieren Sie keinen Systemindex, nur um einen roten Health-Status zu beseitigen, es sei denn, Sie verstehen die Auswirkungen auf Produktebene.