open-telemetry / semantic-conventions

Defines standards for generating consistent, accessible telemetry across a variety of domains
Apache License 2.0
261 stars 167 forks source link

About Span status: Why the span status should be left unset for a successful invocation? #1287

Closed Cirilla-zmh closed 2 months ago

Cirilla-zmh commented 2 months ago

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.

MadVikingGod commented 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.

Cirilla-zmh commented 2 months ago

@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.

lmolkova commented 2 months ago

@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.

Cirilla-zmh commented 2 months ago

@lmolkova Thank you, I understand now.