Closed Cirilla-zmh closed 2 months ago
This guidance is specifically for http instrumentation libraries, like the ones Otel would write. Because Span Status is an application level signal most http libraries can not tell if at the application level a 200 ok was a success, or the response was successful and had a failure in the payload.
e.g. a 200 ok with a payload of: {"error":"unsuccessful", reason:"Not enough Credits"}
.
It's assumed that the users of the http library would interpret that data and set the flag as needed.
@MadVikingGod Thanks a lot for your reply.
That's to say, any remote procedure calls that may carry custom application semantics should not be set to Ok? I think it's a reasonable design.
@Cirilla-zmh yes, generic instrumentations (for remote procedure calls or not) usually don't have enough context to know if something is a success and should not set it.
Instrumentations implemented by application authors for these applications specifically can set status according to their needs.
@lmolkova Thank you, I understand now.
According to https://opentelemetry.io/docs/specs/semconv/http/http-spans/#status, Span Status must be left unset if HTTP status code was in the 1xx, 2xx or 3xx ranges, which leads us to think that the results of this invocation are unknown. However, the 2xx code in the HTTP error code means that this call was successful. In that case, why shouldn't span status be set to
Ok
?Or to put it another way, under what circumstances is span status allowed to be set to ok?
I have searched the relevant issue but did not find a clear cause. I am looking forward to your help.