-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
should StatusCanonicalCode be applied for rpc? #1044
Comments
Good catch, this needs to be updated. Thanks @eddynaka! |
In order to resolve this, we'll need to do two things:
|
Hi @arminru , thanks for mapping! Do you have a timeline to be official in the spec? |
@arminru I think the mapping will have to match the mapping we have defined in the proto, see open-telemetry/opentelemetry-proto#224. And there AFAIK the current proposal is OK -> UNSET, everything else -> ERROR. EDIT: Oh, we have the reverse mapping there and it is not unambiguously reversible because both unset and ok map to OK. But we should be consistent, and should never set Ok from instrumentation. |
@carlosalberto from the issue triage mtg today, assigning to you since you previously worked in this area |
Just to get a clear response. Would that be right the mapping below? For HttpStatusCode:
For RPC:
|
For HTTP, the mapping is already defined (indeed like you describe it) here: https://github.com/open-telemetry/opentelemetry-specification/blob/4b19e006ede63471103925edc6a15ab1d7579944/specification/trace/semantic_conventions/http.md#status For RPC, I think that mapping makes sense, but we need to specify it in the semantic conventions. A PR would be welcome for that 😃 |
Hi @arminru , for gRPC, we already have the |
For the existing See |
from the spec issue triage mtg today, after discussing this issue sounds like this can be changed to allowed-for-ga since it is not a blocker for trace spec freeze |
I don't understand how this cannot be a blocker for GA. The change in the status code spec stomped all over the status code emitted from RPC spans. Without defining a specific tag to carry that status code the receivers of the traces (collector + exporters) won't have any idea how to report the actual RPC status to backends. My team definitely relies on that breakdown of RPC failure codes. I'm 100% in favor of passing this information along in an attribute with key "rpc.grpc.status_code". We need something here otherwise the collectors are going to start dropping a key piece of information when they start receiving Spans from SDKs that have implemented this new status spec. |
It is not a blocker for release since (1) OpenTelemetry as a whole is usable even without it and (2) it can be added after release as a non-breaking change, if it does not make it into the release. |
We just hit this too: open-telemetry/opentelemetry-python#1308. So filed a PR with the results of the discussion. |
What are you trying to achieve?
After the merge of this PR: #966, we can see that the
StatusCanonicalCode
got changed toError
,Unset
, andOk
.But, if we see the rpc status: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/rpc.md#status, they kept the same.
Additional context.
Should the status be the same? How should we map the rpc status to the new
StatusCanonicalCode
? For example:Unkown
is an error or an unset status?cc: @cijothomas @reyang
The text was updated successfully, but these errors were encountered: