Introduce service.peer.name and service.peer.namespace; deprecate peer.service by mmanciop · Pull Request #3097 · open-telemetry/semantic-conventions (original) (raw)

hi @mmanciop!

thanks for taking this on.

we discussed this in yesterday's Service and Deployment Semconv SIG meeting (https://zoom.us/rec/share/W7L9lhkmwN6GGzh1ykMxcF-dr2B0frjOAaO52BSe-8VP-Zag6n15gQObv_sFtqM.OCG1dIwmHpD2D2rP starting around 34:00 minute marker).

I believe we're onboard with renaming peer.service to service.peer.name.

Very nice!

We'd like a bit more understanding of whether service.peer.namespace is needed, since we haven't had that previously, and so it would need to go through a bit more prototyping / discussion.

The identity of a service is the combination of its service.name and, if set, its service.namespace. From https://opentelemetry.io/docs/specs/semconv/resource/:

service.namespace: A string value having a meaning that helps to distinguish a group of services, for example the team name that owns a group of services. service.name is expected to be unique within the same namespace. If service.namespace is not specified in the Resource then service.name is expected to be unique for all services that have no explicit namespace defined (so the empty/unspecified namespace is simply one more valid namespace).

The canonical example in my head is the frontend service: most complex systems have one, and this is where the service.namespace kicks in. If the service on the other side cannot say which application is talking to, but just that it is "some frontend", that nuance is lost.

For service.peer.name, we want to make sure we have a clear path towards stabilizing, as we have strong preference for "defacto stable" things like peer.service to only break once when going to (true) stable. Similar to what we did for HTTP and database semconv.

We still need to decide whether we want to recommend OTEL_SEMCONV_STABILITY_OPT_IN as part of this migration.

Can you investigate the existing usages of peer.service in OpenTelemetry repositories? We'd like to understand how widespread the usage is (outside of the Java agent where we know it has decent usage).

Sure, I had already done the research before coming up with the proposal, and I just spent some more time with GitHuib search to make sure I did not miss anything. To my knowledge, the list is as follow, going through SDKs and contribs in alphabetical order:

Others:

Once we decide on the migration and stabilization plan, we want to communicate it via a short blog post, to hopefully avoid the surprises that folks had with the deployment.environment -> deployment.environment.name change.

Sounds good to me.

I also think that adding one more fallback case for service.peer.name to most of the projects above is not difficult. There is, however, the fact that their semantics of service identity is going to be incomplete anyhow if the logic is not extended to also support service.peer.namespace. But I suspect most stakeholders will answer with "service.namespace, what's that?".