Link to proposal for gRPC metrics

[yashykt]

Changes

Link to specification for gRPC metrics - https://github.com/grpc/proposal/blob/master/A66-otel-stats.md

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• CHANGELOG.md updated for non-trivial changes.
• schema-next.yaml updated with changes to existing conventions.

On running make markdown-link-check, I got the following errors, but I'm ignoring them since I'm not modifying these files -

  ERROR: 2 dead links found in ./docs/runtime/README.md !
  [✖] https://github.com/open-telemetry/opentelemetry-specification/tree/v1.26.0/specification/document-status.md → Status: 0
  [✖] https://github.com/open-telemetry/oteps/pull/108/files → Status: 0

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[jsuereth]

I think there's a few meta-conversations happening over this PR.

1. Is this PR a breaking change?
2. Can gRPC link out to its new o11y specification from the OTEL semconv?
3. Should gRPC participate in generic OpenTelemetry RPC conventions?

Let's try to tone down this PR to just addressing one thing, and we can follow up on the rest. My comments on each.

Is this PR a breaking change?

As written, yes. I would separate the PR that attempts to remove gRPC from generic RPC metrics from the one which adds links to gRPC's own o11y specification.

Can gRPC link out to its new o11y specification form the OTEL semconv?

We allow .NET, e.g. to define their client-library semconv here for OpenTelemetry users. I think having gRPC define its own metrics is in line with that. We can/should accept a link from our semconv on gRPC to the gRPC-owned o11y specification. Generally, OpenTelemetry is more than happy when projects take their own self-o11y into hand and own it / drive it forward themselves.

Should gRPC participate in generic OpenTelemetry RPC conventions?

This is not something OpenTelemetry can force. I think @markdroth presents a lot of rationale and reasons why gRPC thinks it will be more user-friendly for RPC-implementation-specific semantic conventions. I think folks in our community disagree.

My own opinion is nuanced. I don't see the same kind of general specificaiton/abstraction that keeps databases more tightly coupled (e.g. SQL). However, specifically for gRPC spans, I think providing consistent rpc labels could work.

I suggest for the purpose of this PR we leave this discussion out of it, and have that as a sidebar w/ gRPC team.

My suggestion

I think is true today:

• gRPC have their own o11y specification focused on metrics that is inline w/ other implementation-specific documentation we've accepted (.NET e.g.).
• This PR, as it stands, is a breaking change. We cannot allow that without some transition plan.

Let's focus this PR on non-breaking changes to point at gRPC's o11y specification (which we should encourage). @yashykt Could you split the breaking changes into a separate PR?

Let's follow up discussions between our community and @yashykt @markdroth et. al. on gRPC's participation in generic RPC conventions.

[trask]

We allow .NET, e.g. to define their client-library semconv here for OpenTelemetry users. I think having gRPC define its own metrics is in line with that. We can/should accept a link from our semconv on gRPC to the gRPC-owned o11y specification.

👍

We worked heavily with the .NET team when stabilizing the OTel HTTP semantic conventions. They helped influence our HTTP semantic conventions, and we helped influence their .NET specific semantic conventions, and we ended up with a nicely aligned story across both.

I would ❤️ to see the gRPC and OTel communities work together, I believe we can have similar success in the RPC semantic conventions (even more so since we are both under the CNCF umbrella! 🏖️).

@jsuereth and I are both excited to kick off an RPC semantic convention stability working group this year. If there's a time constraint on the gRPC side to get this done, let us know and we can look at kicking it off sooner than later.

[yashykt]

As suggested, I've removed the breaking changes parts of this PR. I don't think there's a time constraint but I think we should try to resolve the concerns earlier rather than later.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[yashykt]

ping

[lmolkova]

@yashykt could you please add a changelog entry?

[yashykt]

@lmolkova Done