Diagnostiquer les rejets 429, la pression sur le heap et les circuit breakers

Commande

# 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

Ce que fait la commande

Affiche les requêtes rejetées parce que les files des thread pools write/search étaient pleines, l'état heap/CPU par nœud, les déclenchements de circuit breakers, le nombre d'old GC et l'utilisation mémoire du fielddata.

Quand l'utiliser

Quand les clients reçoivent 429 Too Many Requests ou es_rejected_execution_exception, qu'une CircuitBreakingException ([parent] Data too large) apparaît, ou que les nœuds subissent de longues pauses GC.

Attention

Les compteurs rejected sont cumulés depuis le démarrage du nœud ; regardez l'augmentation entre deux échantillons. Relever queue_size masque les rejets mais augmente le heap et la latence ; la vraie correction consiste à réduire la taille/concurrence des bulk ou à ajouter de la capacité. Si le heap reste au-dessus de 85 % et que l'old GC s'exécute souvent, le nœud approche de l'OOM. Activer fielddata sur un champ text consomme rapidement le heap.