Proposal: Add Datadog Tracing Support for rueidis

[korECM]

The rueidis library currently supports OpenTelemetry tracing via rueidisotel and provides a hook mechanism through rueidishook.
I propose adding native Datadog tracing support to enhance observability for users of the rueidis Redis client.

[rarguelloF]

Hello! 👋

This sounds like a great addition, so please consider this proposal accepted.

PRs are more than welcome, but if you want us to tackle the work feel free to reach out Datadog Support so we prioritize accordingly.

[korECM]

@rarguelloF
Great! I'll take care of this task!

[korECM]

@rarguelloF

I have some concerns while working on Redis integration.

Unlike go-redis, rueidis doesn't provide a way to inspect Client options once a Client is created. This suggests we should implement the integration using the trace library's NewClient consistently rather than using a WrapClient approach. I'd like to get thoughts on whether this approach makes sense.

// go-redis

// Options returns read-only Options that were used to create the client.
func (c *Client) Options() *Options {
	return c.opt
}

// rueidis

// Client is the redis client interface for both single redis instance and redis cluster. It should be created from the NewClient()
type Client interface {
	CoreClient

	DoCache(ctx context.Context, cmd Cacheable, ttl time.Duration) (resp RedisResult)

	DoMultiCache(ctx context.Context, multi ...CacheableTTL) (resp []RedisResult)

	DoStream(ctx context.Context, cmd Completed) RedisResultStream

	DoMultiStream(ctx context.Context, multi ...Completed) MultiRedisResultStream

	Dedicated(fn func(DedicatedClient) error) (err error)

	Dedicate() (client DedicatedClient, cancel func())

	Nodes() map[string]Client
}

Another concern is about determining which Client type (Single, Sentinel, Cluster) will be created from given Options, which is needed for setting Redis span tags. While we can examine the related logic in rueidis' internal code, there are two main concerns:

1. Is it appropriate for the trace library to depend on the internal logic of rueidis? I'm worried this creates too tight a coupling with the library's internal implementation.
2. Even if we decide to depend on the internal logic, there's a complication: rueidis attempts to create a Cluster Client first, and falls back to Single Client if that fails. This makes it impossible to infer which Client type will be created just by examining the Options. I'm wondering what would be the best approach in this situation.