-
-
Notifications
You must be signed in to change notification settings - Fork 224
New Span Schema #1230
base: master
Are you sure you want to change the base?
New Span Schema #1230
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
72bd300
to
f918ff2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for starting this!
"endTimeUnixNano": "1544712661000000000", | ||
"attributes": [ | ||
{ | ||
"key": "sentry.segment.id", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still not 100% if sentry.segment_id
would be better. I personally like the nesting but the Otel docs are ambiguous about it:
Namespaces can be nested. For example telemetry.sdk is a namespace inside top-level telemetry namespace and telemetry.sdk.name is an attribute inside telemetry.sdk namespace.
but
the fact that an entity is located within another entity is typically not a sufficient reason for forming nested namespaces. The purpose of a namespace is to avoid name clashes, not to indicate entity hierarchies.
https://opentelemetry.io/docs/specs/semconv/general/attribute-naming/
When in doubt, I would keep the .
.
Co-authored-by: Joris Bayer <[email protected]>
To simplify conversion in the future, align attribute names in Otel's span attributes with keys in Sentry's `span.data`. The old keys in `span.data` remain as legacy alias. See also getsentry/develop#1230 for the span schema / attribute convention. ref: #3278 --------- Co-authored-by: David Herberth <[email protected]>
https://develop-git-new-span-schema.sentry.dev/sdk/event-payloads/only-spans/