Add Support for DD_SERVICE_MAPPING Environment Variable

[hykim013]

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

We would like to be able to rename services through configuration with the service mapping env var. This is something we are able to do in Java, Python, etc. but not in Ruby.

In the additional configuration section, we see other env vars that can change the default behavior of Datadog tracing, but service mapping is missing.

Describe the goal of the feature

This is the description from the Configuring the Java Tracing Library page:
Example: mysql:my-mysql-service-name-db, postgres:my-postgres-service-name-db Dynamically rename services via configuration. Useful for making databases have distinct names across different services.

And from Python: Define service name mappings to allow renaming services in traces, for example: postgres:postgresql,defaultdb:postgresql.

Additional context

Here's the request and PR from Java where this was addressed: https://github.com/DataDog/dd-trace-java/issues/65 https://github.com/DataDog/dd-trace-java/pull/314

And from Python: https://github.com/DataDog/dd-trace-py/issues/897 https://github.com/DataDog/dd-trace-py/pull/2031

[TonyCTHsu]

👋 @hykim013 , thanks for the feedback, I will bring this back to our team for planning

[delner]

Thanks for taking the time to describe the issue! The links and context are helpful.

My understanding is that feature flag works by describing the existing default, then another value you'd like to map it to. I think this is not a good fit for our Ruby implementation, for a few reasons:

• Ruby service name defaults are already configurable through service_name options.
• If we change default service names, it will break your service mappings. (Using existing service name options won't.)
• Service name mappings are too coarse, and if applied broadly, may incorrectly map a service name. For example, if there's a 2nd DB with its own client, it may apply the mapped name to that 2nd DB when it shouldn't.
• I have to check, but my sense was this feature flag is Java-centric because of limitations in their configuration. The Ruby library should implement practices idiomatic to Ruby.

I think one thing we can improve, but are currently lacking, is ENV var configurability. We actually are in the process of implementing more ENV vars per integration to make these default service names configurable without having to alter a configuration file. See #2455.

Does that help?

[andrewthauer]

I would vote for keeping these environment variables consistent and supporting DD_SERVICE_MAPPING across all Datadog tracer libraries.

While I can agree that using ruby conventions for code makes a lot of sense; I don't see how using different environment variable names as in #2455 applies the same. For any organization that uses multiple languages, these types of inconsistencies create a lot of cognitive load and frustrations to sort through and figure out what is and isn't supported when configuring the various datadog language specific libraries. Especially if you choose to configure through environment variables entirely which is mostly possible.