Exposing more data on IProfiledCommand to enrich traces

Greetings!

I'm using Open Telemetry and its Redis adapater to instrument an application using a Redis cluster for caching.

There are a couple of issues that have been discussed in this area already. Ideally, we would use DiagnosticSource (#833) because the profiling interface is a bit awkward for the integration (#1044) but let's set that aside for a second.

The profiling mechanism works once you get it registered with the connection, but it's missing some key data, primarily the cache key and whether or not the retrieval was a hit or a miss. That stuff isn't exposed on the IProfiledCommand interface so there's no way for OT to write it on its spans. We can solve this by wrapping our calls into StackExchange.Redis with a class that spins up tracing around it, but it would be nice to have an OOB solution.

Are we open to exposing more data on IProfiledCommand? I'm happy to work on it, and throw up a proposal, I just thought it would be a good idea to ask first.

/cc @SergeyKanzhelev @MikeGoldsmith @cijothomas

Start by locating the IProfiledCommand interface and the profiling mechanism used by StackExchange.Redis. Review the existing profiling data and the related discussions in issues #833 and #1044, then determine how cache keys and hit/miss results could be exposed and verified for OpenTelemetry consumers.