Closed as not planned
Closed as not planned
Description
Currently, all values in Span._attributes
are merged with Span.data
and put into the data
attribute of a JSON span.
Plan for v8:
We use span attributes as a replacement for setting tags or dedicated fields onto a span. For example:
Span.op
(feat(core): DeprecateSpan.op
in favor of op attribute #10189)Span.origin
(feat(core): DeprecateSpan.origin
in favor ofsentry.origin
attribute #10260)http.status_code
tag (feat(core): DeprecateSpan.setHttpStatus
in favor ofsetHttpStatus
#10268) <-- here I'm still setting the tag as well (see below)
The consequences:
- Some fields are duplicated:
jsonSpan.op
& `jsonSpan.data['sentry.op']jsonSpan.origin
& `jsonSpan.data['sentry.origin']
- New fields end up in
span.context.trace
sentry.op
andsentry.origin
- Is this problematic or just unnecessary/redundant data?
- Entries in
span.tags
are (would in the future be) only set onspan.data
http.status_code
tag <-- To avoid this, I ended up duplicating setting the tag and attribute for now in feat(core): DeprecateSpan.setHttpStatus
in favor ofsetHttpStatus
#10268- Potentially a lot more tags as we remove deprecation ignores
- Potentially all user-set tags once they migrate
Solution
I think as long as our backend doesn't handle picking specific keys from span.data
(I have no idea what it does with these currently) to handle them like they were tags, we need to map back things to the original span JSON payloads.
But how are we going to do this reliably?
sentry.op
andsentry.origin
can probably stay duplicated inspan.data
(?)sentry.op
andsentry.origin
don't need to be sent in trace context. But does it hurt us sending them still?- but tags should still be mapped to
span.tags
- do we need to prefix the attribute keys? e.g.
http.status_code
-->tag.http.status_code
? Might work for our internal tags but user tags?
- do we need to prefix the attribute keys? e.g.
Metadata
Metadata
Assignees
Type
Projects
Status
Waiting for: Community