Service renaming

[LikeTheSalad]

OpenTelemetry has become the observability data industry standard for several platforms, especially related to backend services, and, while it probably was not foreseeable at the time of its creation, it has become so widely popular that it's now being used for purposes beyond telemetry for backend services, and moved onto other scopes such as mobile apps and web pages too! Which speaks volumes of how fast this community has grown and it's a testament to the hard work and love that has been put into expanding its capabilities.

As it would happen with any growth story though, as time passes by and OpenTelemetry expands and evolves, some of its parts, which were exactly what was needed at the beginning, might not make too much sense anymore, and one important aspect of it that has been discussed in the Client SIG, is the way to refer to an "entity that produces telemetry", be it a backend service, web app or mobile app for example, all of which, at the moment, would be defined as service, based on the current semantic conventions, which has proven to be confusing for people who are starting to adopt OpenTelemetry for non-backend services purposes.

This PR aims to provide a term to identify an "entity that produces telemetry" in a way that wouldn't be tied to any particular environment so that it better represents the wide range of use cases that OpenTelemetry has come to support in time, and hopefully covers any use case that might arise in the future as well. I'm conscious of the longevity of the current term service and how widely adopted it is across existing services and even non-services entities, which most likely won't make this an easy change for sure, though I believe that, based on how fast OpenTelemetry is growing, the longer we wait to make these kinds of changes, the more difficult it will become.

[t2t2]

Past related issues/pr-s:

• Add service to the glossary opentelemetry-specification#2050
• Add service to glossary opentelemetry-specification#2111
• Add Resource browser and app attributes, clarify device attributes as client-side only opentelemetry-specification#2115
• Add telemetry.source attribute namespace opentelemetry-specification#2192
• Introduce Mandatory Unique Identifier For Telemetry Sources oteps#194

[Oberon00]

service.name is one of the very few semantic conventions that is stable and also referred to in the spec. While I agree that the proposed name sounds much nicer, I much prefer avoiding breaking changes here.

Adapting the description to clarify that service.name can also be used for things that one would not normally think of as services without changing the attribute name would be fine with me

[jsuereth]

+1 to everything @Oberon00 said.

We've had a lot of debates about the term application or service or origin.

In the end, we decided on service and it's too late to break everything right now. At best this PR could propose using both service and origin when something is both the origin of telemetry and a service.

However, this discussion is so wide-sweeping it belongs as an OTEP.

[LikeTheSalad]

It definitely wouldn't be an easy change, as I mentioned in the description, though based on the amount of times an issue about this resource name has been brought up in the past, I think it's definitely an important one because it doesn't feel like service fits well what OpenTelemetry has become, it kind of neglects that other use cases exist or are important, making it not too welcoming or inclusive for potential new users, and unfortunately just adding a description to service that covers other use cases kind of sounds like putting a band-aid on the problem. Is that the best alternative we could go with for this case @Oberon00 ?

[AlexanderWert]

Since service.* is confusing for non-backend use cases. How about (re-)considering to introduce additional concepts for those use cases and making service.* optional for those use cases. Something like client.application.* or mobile.application.*, browser.application.*, etc. that would make it clear that it's not a backend service and with the right prefix setting the right context so it cannot be confused with the service.* concept?

[LikeTheSalad]

Since service.* is confusing for non-backend use cases. How about (re-)considering to introduce additional concepts for those use cases and making service.* optional for those use cases. Something like client.application.* or mobile.application.*, browser.application.*, etc. that would make it clear that it's not a backend service and with the right prefix setting the right context so it cannot be confused with the service.* concept?

Ideally, we should be able to rename service, although if it's really impossible, then this alternative doesn't sound too bad, it's definitely better than just updating service's description.

I'm planning to open an OTEP regarding this when I'm back from PTO as @jsuereth suggested.

[joaopgrassi]

I'm planning to open an OTEP regarding this when I'm back from PTO as @jsuereth suggested.

@LikeTheSalad great, looking forward to the discussions there! I think we can close this PR as nothing will be merged here

[Oberon00]

@AlexanderWert

Since service.* is confusing for non-backend use cases. How about (re-)considering to introduce additional concepts for those use cases and making service.* optional for those use cases.

I don't think this is any better. Having service.name renamed for some or all telemetry senders is in the end the same breaking change for those that receive & interpret these resource attributes.