Diagnose 429 rejections, heap and circuit breaker pressure

Command

# 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

What it does

Shows requests rejected because the write/search thread pool queues were full, heap/CPU state per node, circuit breaker trips, old GC count and fielddata memory usage.

When to use it

When clients get 429 Too Many Requests or es_rejected_execution_exception, CircuitBreakingException ([parent] Data too large) appears, or nodes suffer long GC pauses.

Caution

rejected counters are cumulative since the node started; look at the increase between two samples. Raising queue_size hides rejections but increases heap and latency; the real fix is reducing bulk size/concurrency or adding capacity. If heap stays above 85% and old GC runs often, the node is approaching OOM. Enabling fielddata on a text field consumes heap quickly.