Diagnosticar rejeições 429, pressão no heap e nos circuit breakers

Comando

# 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

O que faz

Mostra as requisições rejeitadas porque as filas dos thread pools de write/search estavam cheias, o estado de heap/CPU por nó, os disparos de circuit breaker, a contagem de old GC e o uso de memória de fielddata.

Quando usar

Quando os clientes recebem 429 Too Many Requests ou es_rejected_execution_exception, aparece CircuitBreakingException ([parent] Data too large) ou os nós sofrem pausas longas de GC.

Atenção

Os contadores rejected são cumulativos desde o início do nó; olhe o aumento entre duas amostras. Aumentar queue_size esconde as rejeições, mas aumenta o heap e a latência; a correção real é reduzir o tamanho/concorrência dos bulks ou adicionar capacidade. Se o heap fica acima de 85% e o old GC roda com frequência, o nó está se aproximando de um OOM. Habilitar fielddata em um campo text consome heap rapidamente.