ddtrace-run: how to put all traces under one service name

[yxing999]

Thanks for taking the time for reporting an issue!

Which version of the libraries are you using?

ddtrace==0.46.0

How can we reproduce your problem?

Following this doc, I wrote a library to set up the config(tag, sampling rate, etc) and used ddtrace-run to enable auto-instrumentation for a Django application. The problem is I got many traces with different service names(as the below link shows). Since we have many applications to send traces, I need to make those traces under one service(or traces from different application will mix, it's hard to view or query them). Every application has different kinds of traces, it's verbose and unreliable to set those name by config like ddtrace.config.django['service_name']=, ddtrace.config.django['cache_service_name']=(there will be a long list in library and may miss some). I didn't find a way to control all service name of them, DD_SERVICE doesn't work, service.name tag work for most of them but not all(request traces still show request name).
I wonder is there a recommended way do configuration in my library that makes APM puts the traces from one application into one service name?

What is the result that you get?

https://drive.google.com/file/d/1vYMyh0NCpK8U_oI2Rpi8bv4DtkMrxxbO/view?usp=sharing

What is the result that you expected?

All traces are under one service name in Datadog APM UI.

[majorgreys]

Right this is certainly difficult to accomplish with the service configuration options the library provides. Thank you for raising this request and we will discuss an approach.

To help, I wanted to raise what I see as a potential problem with setting one service name for all spans. In your example, the django and defaultdb services are being set for the django.cache and the db calls. Overriding them so that they are the same as the service set for the Django app makes sense.

I'm less certain about the external calls made that are captured by the other spans. The service names on those spans are useful to differentiate where time is spent in a request, e.g. "internally" to the Django application itself vs. "external" services like an HTTP or gRPC request. Unless those external endpoints are also instrumented, the spans generated from the Django application would be the only visibility into those operations. Removing these distinctions presents problems elsewhere, such as the latency breakdown in the trace list and the service legend on the trace page.

[yxing999]

Hi, @majorgreys , Thanks for your reply. As my understanding, ideally,

• For the spans generated by application, they should be put into one service in some way(consistent and reliable).
• For the span outside of the application, if the external endpoints are instrumented, they should reside in that service name; if not, putting them into default service name will cause spans from all kinds of services mix there(unless I can instrument the whole organization), so it should be better to have them under this service name(who make the request)? we can still identify them by resources.
• I'd also like to get involved into other solutions for this scenario.

[andrewsouthard1]

Hey @yxing999 - I'm a PM here at Datadog. Would love to discuss this one further. You mind shooting me an email at [email protected] and we can set up a time to chat on what you're looking for?

[fieg]

We are also experiencing this. We have a microservice architecture with multiple flask apps. Now all the flask apps are joined under a single service in the APM view. Metrics like latency don't make sense if they mix different apps. I would expect to have everything logged under the value of the DD_SERVICE variable.

[jwthomp]

In the documentation under django/flask and others, it states the service name Can also be configured via the DD_SERVICE environment variable.

It seems that this is not being honored. Is that a bug, or an error in the documentation?

[ellisvalentiner]

I have the same problem mentioned here.

@jwthomp your comment here is a bit old now but some integrations allow you to specify a DD_<INTEGRATION>_SERVICE environment variable and override. For example, DD_REQUESTS_SERVICE=foo-bar.

However I've found this to be very inconsistently implemented by integration. Thus, while you can resolve the issue for something like requests, you can't solve it for botocore because the DD_BOTOCORE_SERVICE config wasn't implemented.

[justrp]

on a moment (as a workaround?) it's possible to use DD_SERVICE_MAPPING environment variable, but I hope it could be simplified with no explicit listing of services I use within the app

[github-actions[bot]]

This issue has been automatically closed after six months of inactivity. If it's a feature request, it has been added to the maintainers' internal backlog and will be included in an upcoming round of feature prioritization. Please comment or reopen if you think this issue was closed in error.