Add Resilience4j circuit breaker support to Java auto-instrumentation

[DhroovP]

Is your feature request related to a problem? Please describe.

Resilience4j circuit breakers currently aren't surfaced by the Java agent's auto-instrumentation.

When debugging a request that goes through a circuit breaker, it would be useful to have visibility into whether a circuit breaker was involved and its state directly in the trace. This is especially useful when trying to distinguish an actual downstream failure from a request that was short-circuited by Resilience4j.

Describe the solution you'd like

I'd like to see auto-instrumentation support for Resilience4j circuit breakers.

At a minimum, it would be useful to expose information such as:

• circuit breaker name
• circuit breaker state (CLOSED, OPEN, HALF_OPEN, etc.)

I'm not sure whether these are best represented as span attributes, events, or something else based on existing OpenTelemetry semantic conventions, so I'd be happy to follow whatever approach makes the most sense here. In my opinion, span attributes make the most sense.

I'm also happy to contribute the implementation if there is interest in adding this.

Describe alternatives you've considered

This can be implemented today with custom/manual instrumentation or application-specific hooks into Resilience4j, but it would be nice to have this available out of the box when using the Java agent rather than requiring every application to instrument it independently.

Possible telemetry model

I'm not strongly opinionated on the exact modeling here, but as a starting
point I could see the instrumentation enriching the relevant span with
Resilience4j circuit breaker information, for example:

• resilience4j.circuit_breaker.name
• resilience4j.circuit_breaker.state
• an indication that execution was rejected/short-circuited by the circuit breaker

Summary

Being able to see something like the circuit breaker name and current state alongside the trace is surprisingly useful when debugging resilience/failure behavior.

[DhroovP]

After writing this request, one thing I thought about is whether the attributes should ultimately be generic to circuit breakers rather than specific to the Resilience4j library.

I think that’s probably the right direction long-term, but I’d like to keep this issue pretty focused if possible. The immediate goal is just to get enough information into the span to distinguish a downstream failure from a request that was rejected by an open circuit breaker.

I don’t think we need to solve the broader resilience semantic-conventions question in order to make that useful, and I’d prefer not to block the initial instrumentation on it.

The implementation can be kept flexible enough to revisit the attribute naming/model later. Of course, if there are concerns that this approach would make that difficult, I’m happy to reconsider.

[jkwatson]

Moving over to the instrumentation repo.