[Question/FR] Index Pressure as Circuit Breaker

[stefnestor]

👋🏼 I recently learned that Coordinating Nodes can reject requests due to Index Pressure saturation. This sounds like a Circuit Breaker to me, but it is not listed with the larger group.

As a Kibana user, both induce a HTTP 429, though if I inspect error they have different response bodies. I can see via Node Stats that they return under separate sub-objects:

• index pressure: GET _nodes/stats?filter_path=nodes.*.indexing_pressure
• circuit breakers: GET _nodes/stats?filter_path=nodes.*.breakers

I believe you only really know they're different by checking Elasticsearch Cluster Logs for CircuitBreakingException though AFAICT you react to coordinating_rejections the same the [parent, request, inflight_requests] Circuit Breakers.

(Note: AFAICT this does not overlap with #62223, but my apologies if I've misunderstood.)

Request: Can you help me understand if Index Pressure is intended to be/become a Circuit Breaker type? If not, could it (and this issue become a feature request)? If not to both, can you send me an example of coordinating_rejections induced Elasticsearch log to help me separate these in my mind? 🙏🏼

TIA!

[elasticmachine]

Pinging @elastic/es-docs (Team:Docs)

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[DaveCTurner]

The indexing pressure subsystem is distinct from the circuit breaker subsystem, although they're certainly similar concepts. If you exceed the indexing pressure limits you get an EsRejectedExecutionException and not a CircuitBreakingException. The separation is intentional and there are no plans to try and merge these subsystems together. I don't really understand the benefits this would bring.

I'm not sure we record anything in the logs when exceeding indexing pressure limits. We generally try and avoid per-request log messages since they can result in overwhelming volume and aren't all that useful for the server admin to see. It's up to the client to keep track of this sort of thing since the client is the component that needs to deal with the problem by backing off and perhaps applying backpressure upstream. You can determine the rejection behaviour yourself by setting indexing_pressure.memory.limit to something very low and trying to index some documents.