[rueidis] Add option for conditional span creation based on context

[guilemieux]

Package Name

redis/rueidis

Package Version(s)

v2.1.0 (also tested with v2.4.0)

Describe the feature you'd like

Add an option to conditionally create spans based on the request context.

Proposed API:

rueidis.NewClient(clientOption,
    rueidis.WithService("my-redis"),
    rueidis.WithSpanFilter(func(ctx context.Context) bool {
        // Return true to create a span, false to skip
        return shouldTrace(ctx)
    }),
)

This would allow users to skip span creation for requests that aren't being sampled, reducing overhead while still benefiting from rueidis' client-side caching with a single client instance.

Is your feature request related to a problem?

Yes. Creating spans for requests that won't be sampled/traced consumes significant CPU in high-throughput services.

We process thousands of Redis requests per second, but only a small percentage of requests are actually traced (based on Datadog's sampling). Currently, the rueidis integration creates spans for every request regardless of sampling decision, which adds unnecessary overhead:

• Span object allocation
• Tag building and string operations (processCommand, resource name construction)
• Context wrapping
• Span finishing and cleanup

We determine the sampling priority early in the request lifecycle (stored in context). We'd like to skip span creation entirely for requests we know won't be traced, reducing CPU usage while still getting full tracing for sampled requests.

Describe alternatives you've considered

Two separate rueidis clients (traced + non-traced)

Route requests to either client based on sampling decision in context.
Problem: Breaks rueidis' client-side caching. Each client has its own independent cache, so cache entries aren't shared. A key cached via the traced client won't be found when querying via the non-traced client, reducing the cache hit rates.

Always use the traced client

Let DD handle sampling internally and create spans for all requests.
Problem: Span creation overhead is non-trivial at high throughput. Even if spans aren't exported, we still pay for object allocation, string building, and context wrapping on every Redis call.

Custom wrapper mimicking dd-trace-go internals (current workaround)

We created our own client that copies the dd-trace-go rueidis implementation but adds a context check before span creation.
Problem: Requires maintaining code that duplicates dd-trace-go internals. When dd-trace-go updates (new tags, bug fixes, features), our wrapper falls out of sync.

Additional context

No response