Semantic convention for a remote service name

[anuraaga]

Many tracing systems rely on client/server spans having a well defined service name. For example, if there is a service with two methods, UserCache.Get and UserCache.Store, then the service name in this case is UserCache. Tracing systems use this to create dependency graphs showing what services are depending on what other services.

We currently provide the service.name on Resource

https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/semantic_conventions/README.md#service

This can be used as the service name for server spans. However, it is also important for client spans to have a service name.

1. While most tracing systems will be able to combine server/client spans in a way that the server span's service name is the ground truth, not all of them can

2. Some servers are not traced, in particular databases currently are rarely instrumented and rely on client spans to show up in traces / service graphs.

OpenTracing has peer.service, Zipkin has endpoint.serviceName, and I think we need something similar here too that applies to all client spans as a general concept and give the user the ability to set this to a name that makes sense to them (if the UserCache above is a redis database, the words UserCache will not appear anywhere in the protocol and possibly not int he URL. It is a semantic concept defined by the user and needs to be settable).

How about adding peer.service to the general conventions at https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/span-general.md ?

Note, this should not be confused with net.peer.name which is defined as the DNS name. It is not uncommon for a single service to be accessed from multiple DNS endpoints, due to sharding or similar, but still is a single service in terms of a service graph.

[yurishkuro]

Correction: OpenTracing has peer.service, not peer.name

peer.service: Remote service name (for some unspecified definition of "service"). E.g., "elasticsearch", "a_custom_microservice", "memcache"

https://github.com/opentracing/specification/blob/master/semantic_conventions.md

+1 for having it as a standard (optional) field for inbound/outbound spans.

peer.service is shorter than peer.service.name but just as expressive imo.

[anuraaga]

Oops thanks for noticing, fixed to prevent confusion and like the shorter name

[iNikem]

I want to spell out one problem here. If this gets to spec, then autoinstrumentations for all languages should be able to somehow fill that value as well. Should those concerns be part of this and similar spec changes proposals? E.g. to provide an example or suggestions, how value can be obtained by autoinstrumentations.