Wesentliche Werkzeuge und Techniken zum Debuggen von Elasticsearch-Cluster-Problemen

Elasticsearch-Cluster-Probleme zeigen sich normalerweise als red oder yellow Health-Status, langsame Suchanfragen, abgelehnte Schreibvorgänge oder Nodes, die aus dem Cluster fallen. Der schnellste Weg, sie zu debuggen, ist, mit der Cluster-Health zu beginnen und dann das Problem auf Shards, Nodes, Allokationsregeln, Logs oder Ressourcendruck einzugrenzen.

Diese Anleitung führt durch die integrierten Werkzeuge, die Sie am häufigsten verwenden werden: _cat-APIs, _cluster/allocation/explain, Node-Statistiken, ausstehende Aufgaben und Elasticsearch-Logs.

Elasticsearch-Cluster-Health verstehen

Die Cluster-Health gibt Ihnen das erste Signal:

green: Alle Primär- und Replica-Shards sind zugewiesen.
yellow: Alle Primär-Shards sind zugewiesen, aber ein oder mehrere Replica-Shards sind es nicht.
red: Ein oder mehrere Primär-Shards sind nicht zugewiesen, daher sind einige Daten nicht verfügbar.

Ein yellow-Cluster kann weiterhin Lese- und Schreibvorgänge für verfügbare Primär-Shards bedienen, hat aber weniger Redundanz. Ein red-Cluster erfordert sofortige Untersuchung, da betroffene Primär-Shards nicht verfügbar sind.

Beginnen Sie mit den `_cat`-APIs

Die _cat-APIs sind für schnelle, menschenlesbare Überprüfungen konzipiert.

curl -X GET "localhost:9200/_cat/health?v"
curl -X GET "localhost:9200/_cat/nodes?v&h=name,ip,heap.percent,ram.percent,cpu,disk.used_percent,load_1m,node.role"
curl -X GET "localhost:9200/_cat/shards?v"
curl -X GET "localhost:9200/_cat/indices?v"

Verwenden Sie _cat/health, um den Gesamtzustand zu bestätigen. Verwenden Sie _cat/shards, um UNASSIGNED, INITIALIZING oder sich wiederholt verlagernde Shards zu finden. Verwenden Sie _cat/nodes, um Heap-, CPU- oder Festplattenauslastung auf einem bestimmten Node zu erkennen.

Für einen red- oder yellow-Cluster gibt Ihnen dieser Befehl eine fokussierte Ansicht:

curl -X GET "localhost:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node&s=state,index"

Shard-Allokation erklären

Wenn ein Shard nicht zugewiesen ist, sagt Ihnen _cluster/allocation/explain, warum Elasticsearch ihn nicht platzieren kann.

curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" \
  -H 'Content-Type: application/json' -d'
{
  "index": "my_index",
  "shard": 0,
  "primary": true
}'

Sie können Elasticsearch auch bitten, das erste nicht zugewiesene Shard zu erklären, das es findet:

curl -X GET "localhost:9200/_cluster/allocation/explain?pretty" \
  -H 'Content-Type: application/json' -d'{}'

Lesen Sie die Felder can_allocate, allocate_explanation und node_allocation_decisions. Häufige Ursachen sind Festplatten-Watermarks, Allokationsfilter, fehlende Nodes, inkompatible Indexeinstellungen oder zu wenige Daten-Nodes für die angeforderte Replica-Anzahl.

Node- und Cluster-Statistiken überprüfen

Wenn die Health grün ist, aber Suchanfragen oder Schreibvorgänge langsam sind, überprüfen Sie den Ressourcendruck.

curl -X GET "localhost:9200/_nodes/stats/jvm,fs,os,process,thread_pool?pretty"
curl -X GET "localhost:9200/_cluster/stats?pretty"

Achten Sie auf hohe JVM-Heap-Auslastung, Festplattendruck, abgelehnte Such- oder Schreibaufgaben und Nodes mit deutlich höherer Last als ihre Peers. Ein einzelner überlasteter Node kann den gesamten Cluster verlangsamen, wenn er heiße Shards besitzt.

Für Thread-Pool-Ablehnungen verwenden Sie:

curl -X GET "localhost:9200/_cat/thread_pool/search,write?v&h=node_name,name,active,queue,rejected,completed"

Abgelehnte Aufgaben bedeuten normalerweise, dass der Node mit der Anfragelast nicht Schritt halten konnte. Beheben Sie die Ursache, bevor Sie Warteschlangen erhöhen: Reduzieren Sie die Abfragekosten, verteilen Sie Shards, skalieren Sie Nodes oder verlangsamen Sie das Bulk-Indizieren.

Ausstehende Aufgaben und Wiederherstellung überprüfen

Wenn sich Cluster-Zustandsänderungen festgefahren anfühlen, überprüfen Sie ausstehende Aufgaben:

curl -X GET "localhost:9200/_cluster/pending_tasks?pretty"

Eine lange Warteschlange kann auf Master-Node-Druck, häufige Mapping-Updates, Shard-Churn oder instabile Nodes hinweisen.

Für Shard-Verschiebung und -Wiederherstellung verwenden Sie:

curl -X GET "localhost:9200/_cat/recovery?v&active_only=true"

Dies hilft Ihnen, einen Cluster, der aktiv wiederherstellt, von einem zu unterscheiden, der durch Allokationsregeln oder fehlende Daten blockiert ist.

Elasticsearch-Logs lesen

Elasticsearch-Logs erklären oft, was die APIs nur andeuten. Überprüfen Sie die Logs auf dem betroffenen Node, nicht nur auf einem zufälligen Node im Cluster.

Suchen Sie nach Nachrichten wie:

master not discovered
flood-stage disk watermark
circuit_breaking_exception
rejected execution
failed to obtain node locks
shard failed

Zum Beispiel kann ein Flood-Stage-Festplatten-Watermark Schreibvorgänge blockieren, indem betroffene Indizes auf schreibgeschützt gesetzt werden, bis der Festplattendruck behoben ist. Nachdem Sie Speicherplatz freigegeben oder Kapazität hinzugefügt haben, entfernen Sie den Schreibblock nur, nachdem Sie verstanden haben, warum die Festplatte voll wurde:

curl -X PUT "localhost:9200/*/_settings?expand_wildcards=all" \
  -H 'Content-Type: application/json' -d'
{
  "index.blocks.read_only_allow_delete": null
}'

Ein praktischer Debugging-Ablauf

Verwenden Sie diese Reihenfolge, wenn Sie nicht sicher sind, wo Sie anfangen sollen:

Überprüfen Sie _cat/health?v, um zu sehen, ob das Problem clusterweit ist.
Verwenden Sie _cat/shards?v, um nicht zugewiesene, verlagernde oder heiße Shards zu finden.
Führen Sie _cluster/allocation/explain für nicht zugewiesene Shards aus.
Überprüfen Sie _cat/nodes auf Heap, CPU, Festplatte und Node-Rollen.
Überprüfen Sie Node-Logs auf Allokations-, Festplatten-, JVM- und Circuit-Breaker-Nachrichten.
Verwenden Sie Node-Statistiken und Thread-Pool-Statistiken, wenn das Problem Latenz oder abgelehnte Anfragen ist.

Wichtigste Erkenntnis

Das Debuggen von Elasticsearch funktioniert am besten, wenn Sie von breiten Health-Checks zu dem genauen Shard, Node oder der Einstellung übergehen, die das Problem verursacht. Beginnen Sie mit _cat/health, _cat/shards und Allocation Explain, verwenden Sie dann Logs und Node-Statistiken, um die Grundursache zu bestätigen, bevor Sie Einstellungen ändern.