-
Notifications
You must be signed in to change notification settings - Fork 897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inheritable Attributes #1337
Comments
Shouldn't this be done on the backend? Maybe a feature-request for the collector? Especially since "user ID" is mentioned as an example, this sounds very similar to the proposed "Session" concept of open-telemetry/oteps#169 |
I'd prefer to see us expand on baggage specification for this use case. |
The term "trace scoped attributes" has been used to describe this idea. I see this as another opportunity to add semantics via a schema file. Whether propagated via baggage or inferred at the backend, the semantics should be clear. |
I made a library at Form Energy which we've open-sourced, which lets you set attributes within context, and then all contained spans/events pick them up. Here's a quick example of how we use it. It would be great to see a feature like this incorporated into the SDK! from form_observability import ContextAwareTracer, ctx
_trace = ContextAwareTracer(__name__)
with _trace.start_as_current_span("my_span", {"my_attribute_1": my_attribute_value_1}):
# You can open a span, or just a context by itself.
with ctx.set({"my_attribute_2": my_attribute_value_2}):
# There could be many intervening function calls and spans.
# Spans and events in this context automatically have the my_attribute_1
# and my_attribute_2 attributes set on them.
_trace.add_event("my_event") |
I created an OTEP for "Context Scoped attributes" open-telemetry/oteps#207 that proposes to solve this, that code snippet looks pretty much the same as what that OTEP would enable (except that it would not apply the attributes to span events): |
This probably applies specifically to tracing but the attribute specification is under the common directory.
What are you trying to achieve?
It's my opinion that it would be beneficial if attributes could be "inheritable" meaning that any such attributes applied to a parent span would be reflected on any child spans of that parent span. This would be helpful in those use cases where you are tracing multiple spans over the duration of a request and you want to reflect a common attribute, such as a user ID, on every span recorded during that trace.
There is some overlap between this suggestion and with baggage, but baggage isn't necessarily associated with the current trace and I don't believe there is a part of the specification which suggests which baggage should or shouldn't be propagated between services.
The text was updated successfully, but these errors were encountered: