Add ability to set service name prefix

[brettlangdon]

It would be nice to have the ability to set a global service name prefix that gets applied to all services.

This was originally suggested in comments for #547 https://github.com/DataDog/dd-trace-py/issues/547#issue-355345419 https://github.com/DataDog/dd-trace-py/issues/547#issuecomment-444219035

cc @goodspark and @eedwards-sk

[eedwards-sk]

Thanks @brettlangdon <3

[goodspark]

Thanks for opening this, but I think this is slightly different from my last comment (https://github.com/DataDog/dd-trace-py/issues/547#issuecomment-462074146).

I'd still like some way to have a better break out of service names based on actual resource URLs. Or something more specific than just "postgres" or "memcached". Imagine how in 'prod' I might have 50 different services, lets say 10 of them are using their own postgres DB instances/clusters.

If you were to look at the service map for such a layout, what would it look like? My guess is you'd see 10 edges to a 'postgres' node. But all 10 of those DB instances/clusters are independent of each other, right? The same argument for memcached, lambda, etc, etc. I haven't actually tested this for DBs, but I already see similar side effects for 'grpc' "mega-nodes" in the service map. Example:

When in reality, a call to grpc-based service A has nothing to do with grpc-based service B. All my grpc calls don't go through some single grpc routing service that I'm running.

Right now to get better break outs of services, I'm having to reach around and use an undocumented-but-public SQLAlchemy tracing function (trace_engine specifically, and undocumented as as of https://github.com/DataDog/dd-trace-py/pull/261) and manually set the service name, based on the DB URL and DB name. I don't have an idea on how to do this for memcached clusters/instances, lambdas, etc yet.

As a point-of-reference, the Python requests patching has an option to split outgoing traced requests by domain name (the split_by_domain option). This is more what I'm looking for, although it's not so easy to define for things like DBs, cache clusters, etc (eg. How do you uniquely name SQLite in-memory DBs used by different services? What about cache clusters that are effectively load balanced on the client-side via consistent hashing mechanisms? Should those all be different "cache" services, each with their unique endpoint? My gut reaction is no, but then that makes service naming even trickier).

Perhaps another question is in order: How does Datadog recommend we name services to get the most benefit out of all of DD's services (APM, service maps, trace analytics, logging, monitoring, watchdogs, etc)?

If you look at https://docs.datadoghq.com/tracing/visualization/#services, notice how even the documentation is using a service name that isn't normally possible using ddtrace's latest implementation (I'm referring to the quote, "The screenshot below is a microservice distributed system for an e-commerce site builder. There’s a web-store, ad-server, payment-db, and auth-service all represented as services in APM.") because you'd just end up with something like "postgres" or "mysql" or "sqlite", not "payment-db".

[brettlangdon]

@goodspark this is actually a really great and clear explanation of the problem you are having, since it is still a little different from service name prefixes, I opened #1059 with a copy/paste of your above comment.

Please let me know if the issue title should be different, tried to make it generic enough to cover the broad issue rather than focus just on databases.

[brettlangdon]

I am going to close this issue since it has been open with no activity for a long time.

There are some changes planned for service naming (cannot provide an ETA at this time) which will improve the experience overall, but would not be compatible with this request.