Align gRPC server status code to span status code

[dragon3]

This pull request fixes #122

refs:

• BREAKING: Change span statuses for gRPC server spans open-telemetry/opentelemetry-specification#3333
• Align gRPC server status code to span status code open-telemetry/opentelemetry-go-contrib#3685

[CLAassistant]

All committers have signed the CLA.

[akshayjshah]

Thank you for the contribution, @dragon3! This repository - and the OpenTelemetry RPC semantic conventions - are in a strange state right now, because Google's gRPC projects are planning to directly support OpenTelemetry, but they don't plan to follow the OTel RPC semantic conventions. (See grpc/proposal#380 for details.) If Google's gRPC implementations aren't following the proposed semantic conventions, there may not be much value in us following it either.

Before merging this PR, we'd like to discuss the best path forward a bit more among the maintainers, followed by a more open discussion on a GitHub issue. Let's keep this PR open until we make a decision.

[dragon3]

@akshayjshah
Thank you for the reply.

I didn't know the situation and it's interesting 😅 I also find grpc/proposal#389
I hope Google's gRPC implementation will follow the OTel semantic conventions for both metrics, and tracing ( also logging in the future )

Let me explain my motivation to create this PR.

I develop and maintain both gRPC and ConnectRPC services every day for my company. Of course, I use OpenTelemetry for both gRPC and ConnectRPC services observability. That's great but the difference in the span status code between them is a bit hassle.

For example, in gRPC NOT_FOUND span status is Unset, it's good to me to monitor the service's error rate and alerting. But in ConnectRPC the status is Error, it's not great to me because it's expected one and I don't want to count as error, then hard to monitor the service.

I'd like to unify the span status ( follow the current gRPC's status ), that's my motivation.

Anyway, I'm looking forward to your decision. Thank you!

[jhump]

@dragon3, I think we've come around to wanting to merge this change. It looks like it will only bring us closer to Google's gRPC implementation, which is the desired direction. (The main initial concern was trying to adhere to an Otel spec that Google's gRPC implementation does not follow.)

Do you mind rebasing this pull request?

[dragon3]

@jhump
Thank you for the comment. I've just rebased this pull request. Please take a look when you get a chance.

[jhump]

@dragon3, can you address the lint issues? BTW, you can run the linter locally, before pushing commits to GitHub, by running make lint.

[dragon3]

@jhump
I've fixed the lint errors with make lint 😄 Please run CI and check the result again 🙏

[jhump]

Thanks for the contribution, @dragon3

[dragon3]

@jhump
Thank you for reviewing and merging 👍

Could you create a new tag including this change?

[jhump]

Could you create a new tag including this change?

@dragon3, I think we can do that later this week. I'm hoping to get one more change (maybe two) merged before cutting the next release.

[dragon3]

@jhump
Sorry for asking again, but could you create a new tag?
Thank you!

[jhump]

@dragon3, apologies for the delay, and thanks for pinging me about it. v0.7.0 is now released.

[dragon3]

@jhump Thank you!