Diagnosticar rechazos 429 y la presión de heap y 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

Qué hace

Muestra las peticiones rechazadas porque las colas de los thread pools write/search estaban llenas, el estado de heap/CPU por nodo, los disparos de circuit breakers, el número de old GC y el uso de memoria de fielddata.

Cuándo usarlo

Cuando los clientes reciben 429 Too Many Requests o es_rejected_execution_exception, aparece CircuitBreakingException ([parent] Data too large) o los nodos sufren pausas de GC largas.

Precaución

Los contadores rejected son acumulados desde el arranque del nodo; mire el aumento entre dos muestras. Subir queue_size oculta los rechazos pero aumenta el heap y la latencia; la solución real es reducir el tamaño/la concurrencia de bulk o añadir capacidad. Si el heap se mantiene por encima del 85% y el old GC se ejecuta a menudo, el nodo se acerca a un OOM. Habilitar fielddata en un campo text consume heap rápidamente.