Add common guidance on recording errors on spans and metrics, clarify DB conventions#1716
Conversation
There was a problem hiding this comment.
Copilot reviewed 5 out of 20 changed files in this pull request and generated no comments.
Files not reviewed (15)
- docs/database/redis.md: Evaluated as low risk
- docs/database/cassandra.md: Evaluated as low risk
- docs/database/cosmosdb.md: Evaluated as low risk
- docs/rpc/rpc-spans.md: Evaluated as low risk
- docs/messaging/messaging-spans.md: Evaluated as low risk
- docs/cli/cli-spans.md: Evaluated as low risk
- docs/http/http-spans.md: Evaluated as low risk
- docs/general/recording-errors.md: Evaluated as low risk
- docs/gen-ai/gen-ai-spans.md: Evaluated as low risk
- docs/faas/faas-spans.md: Evaluated as low risk
- docs/exceptions/README.md: Evaluated as low risk
- docs/database/elasticsearch.md: Evaluated as low risk
- docs/database/database-spans.md: Evaluated as low risk
- docs/database/mongodb.md: Evaluated as low risk
- docs/database/couchdb.md: Evaluated as low risk
4c1fdc3 to
456f377
Compare
4558c9c to
4ddc1d1
Compare
jsuereth
left a comment
There was a problem hiding this comment.
This looks good to me, but we may want to give some vendors extra time to adjust to the new span status guidance.
|
@jsuereth I'm fine keeping it open, I don't think it's necessary though: The only change from what we recommend today is to stop recording handled exceptions and stop reporting The
So I think the guidance just catches up with existing practice and vendors don't need to change anything. I'll announce it at the Maintainers call on Mon 1/13 and Spec call on 1/14 to make sure everyone is aware. Unless there is some pushback, I'm going to merge it on ~1/15. |
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
1c00b5a to
1f37350
Compare
… DB conventions (open-telemetry#1716) Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Fixes #1536, #1516
error.typeas generic error attribute on spans and metricsdb.response.status_codesas failuresImportant
We can and should implement strategy of reporting exceptions on local root spans in OTel SDK - it should not be an instrumentation concern.
Here's an OTEP on how to record exceptions on logs - it discusses the details of configurable exception recording strategy.
Since public facing log API is in development, we'll keep using span events for the time being.
Merge requirement checklist
[chore]