429-Ablehnungen, Heap- und Circuit-Breaker-Druck diagnostizieren

Befehl

# Thread pool queue and rejection counts (source of 429):
GET _cat/thread_pool/write,search,get?v&h=node_name,name,active,queue,rejected,completed,size,queue_size&s=rejected:desc
GET _cat/nodes?v&h=name,node.role,heap.percent,ram.percent,cpu,load_1m,disk.used_percent,master&s=heap.percent:desc
# Circuit breaker trips and parent breaker usage:
GET _nodes/stats/breaker?filter_path=nodes.*.name,nodes.*.breakers.*.tripped,nodes.*.breakers.parent
GET _nodes/stats/jvm?filter_path=nodes.*.name,nodes.*.jvm.mem.heap_used_percent,nodes.*.jvm.gc.collectors.old
# Fielddata memory usage (per field):
GET _nodes/stats/indices/fielddata?fields=*&filter_path=nodes.*.indices.fielddata

Was es tut

Zeigt Anfragen, die wegen voller Warteschlangen der Write-/Search-Thread-Pools abgelehnt wurden, Heap-/CPU-Zustand pro Knoten, ausgelöste Circuit Breaker, Anzahl der Old-GCs und Fielddata-Speicherverbrauch.

Wann einsetzen

Wenn Clients 429 Too Many Requests oder es_rejected_execution_exception erhalten, CircuitBreakingException ([parent] Data too large) auftritt oder Knoten unter langen GC-Pausen leiden.

Vorsicht

rejected-Zähler kumulieren seit dem Start des Knotens; betrachte den Anstieg zwischen zwei Messungen. Ein höheres queue_size verdeckt Ablehnungen, erhöht aber Heap und Latenz; die eigentliche Lösung ist, Bulk-Größe/Parallelität zu verringern oder Kapazität hinzuzufügen. Bleibt der Heap über 85% und läuft Old GC häufig, nähert sich der Knoten einem OOM. Fielddata auf einem text-Feld zu aktivieren verbraucht schnell Heap.