You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 issue 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.
The proposed name to replace it with is origin, more details on what the change would look like in this PR.
The text was updated successfully, but these errors were encountered:
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 issue 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.The proposed name to replace it with is
origin
, more details on what the change would look like in this PR.The text was updated successfully, but these errors were encountered: