gRPC Client/Server Configuration for Inferred Peer Services (dd-trace-go ≥ v1.53.0)

[identifysun]

Hi Datadog team,

I'm working with dd-trace-go and exploring the inferred service naming functionality introduced in version v1.53.0.

As per the release notes, the Go tracer supports inferred peer service names for outbound dependencies. I understand this can be enabled by setting the following environment variables:

DD_TRACE_PEER_SERVICE_DEFAULTS_ENABLED=true
DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED=true

We are using gRPC for inter-service communication and want to ensure spans show correct service-to-service mappings in the Trace Map, especially in a BFF architecture where one service (A) calls many others (B, C, D...) via gRPC.

Questions:

1. What is the recommended way to configure the gRPC client and server interceptors in this scenario using dd-trace-go, when the proto-defined service names (e.g., tts.UserService) don't match the target service's actual DD_SERVICE value (e.g., user-service)?

2. Should we use grpctrace.WithSpanOptions(tracer.Tag(ext.PeerService, "user-service")) in client interceptors to override the inferred service name? Or is it better to rely on DD_TRACE_PEER_SERVICE_MAPPING for all such mappings?

3. Do you have an example of best practices for configuring gRPC tracing (both client and server) to take full advantage of the inferred peer service naming mechanism?

We want to avoid the fallback grpc.client/grpc.message naming and ensure accurate, clean service relationships in both the Trace Map and service overview dashboards.

Thanks for your guidance!

[felixge]

IDK the answer of the top of my head. If you're in need of a timely response, I'd suggest to raise a request with our helpdesk.

[identifysun]

Thank you