opentelemetry-go
opentelemetry-go copied to clipboard
open-telemetry
usage / documentation of SetStatus is unclear
https://github.com/open-telemetry/opentelemetry-go/pull/2893#discussion_r873927516
By default, the status for all spans is Unset. In rare cases, you may also wish to set the status to Ok. This should generally not be necessary, though.
What are "rare cases"? It seems odd that the documentation advises setting a status for error cases but leaving it unset otherwise.
https://github.com/open-telemetry/opentelemetry-go/pull/2893/files/2209f1bffda2fb9a05528de935fbdff12790ed50#diff-ec6e36363c3666fba4db25039ebb27f440829a94dc48c77c3f59c8ad199db244=
https://opentelemetry.io/docs/instrumentation/go/getting-started/
- setting the status before recording an error - This differs from the "Getting Started" documentation.
- Similarly, why use "operationThatCouldFail failed" for the description as opposed to err.Error(). Is there a best practice?
If you look at the specification: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status
It mentions:
The operation has been validated by an Application developer or Operator to have completed successfully.
I read this as the status should only be set for spans that have somehow been manually validated. In the case of server-side apps, it seems very unlikely we would need it. In the case of frontend apps however, there could be a manual action to trigger a success. Also, per the specification, once a span is marked as OK, it can't ever be marked as Error again.
setting the status before recording an error - This differs from the "Getting Started" documentation.
Frankly, that doesn't matter. None of those methods can return an error, so running them in one order of the other won't change anything.
Similarly, why use "operationThatCouldFail failed" for the description as opposed to err.Error(). Is there a best practice?
I don't know if there's any "best practices" here. Both would work, and really depend on your need, though additional context is always better.
