-
Notifications
You must be signed in to change notification settings - Fork 179
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
Faas: Add an option to use the X-Ray env var as main parent. #263
Faas: Add an option to use the X-Ray env var as main parent. #263
Conversation
This is done in order to help users migrating from the previous behavior (which is offered via this new flag) and the new approach (which uses links).
@@ -66,6 +66,10 @@ contain an incomplete trace context which indicates X-Ray isn’t enabled. The e | |||
`Context` will be valid and sampled only if AWS X-Ray has been enabled for the Lambda function. A user can | |||
disable AWS X-Ray for the function if the X-Ray Span Link is not desired. | |||
|
|||
Instrumentation SHOULD include an explicit option to use `Context` in `_X_AMZN_TRACE_ID` as parent insted of `Link`, |
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.
Instrumentation SHOULD include an explicit option to use `Context` in `_X_AMZN_TRACE_ID` as parent insted of `Link`, | |
Instrumentation SHOULD include an explicit option to use `Context` in `_X_AMZN_TRACE_ID` as parent instead of `Link`, |
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.
It's my understanding this is a temporary stop-gap to help existing user migrate.
We should use similar language/terminology as was done in http semconv about migration period here. See: https://github.com/open-telemetry/semantic-conventions/tree/main/docs/http
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.
Really? I think having an option to use the X-Ray context as parent seems OK also long-term. Though I would change the behavior slightly to always include the link in addition.
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.
More than just "OK", it is imperative that X-Ray users have the ability to utilize the X-Ray span context that is provided to them by the Lambda service. We cannot have a system that makes that impossible and should not have one that leaves it to the instrumentation author to decide whether that category of users should be supported.
What benefit would be gained from having the same span context both as parent and as a link?
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.
What benefit would be gained from having the same span context both as parent and as a link?
The benefit would be that the link would always be there independent of any instrumentation configuration.
(It could also be compared against the parent to determine if the source was X-Ray, but if that is a common use case we would be better of with a "parent_source" span attribute mirroring the link "source" attribute)
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.
I think some of the flexibility across the semantic conventions is intentional in order to cover a broader range of (future) third-party instrumentations. I personally expect all instrumentations published under the OpenTelemetry org to follow all "Recommendeds" and SHOULDs, though I don't think we've had this discussion as a community (I've added this question to next week's semconv meeting).
I generally agree that SHOULD
means "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." I do not agree that there can be no other course taken as SHOULD
is not MUST
. I expect that maintaining compatibility while experimental specification language is being worked on to be a good reason for "choosing a different course".
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.
I expect that maintaining compatibility while experimental specification language is being worked on to be a good reason for "choosing a different course".
👍
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.
(at the same time, adopting the latest semconv in instrumentations is the best way to get real user feedback which can be cycled back into semconv before it gets marked as stable)
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.
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.
(at the same time, adopting the latest semconv in instrumentations is the best way to get real user feedback which can be cycled back into semconv before it gets marked as stable)
I think that's what happened here. The real user feedback was "this broke every existing usage of this instrumentation with no way to make it work again".
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.
Looks good. I thought we had agreed on some sort of deadline to come up with a longer term fix. Is that not part of this PR?
@@ -66,6 +66,10 @@ contain an incomplete trace context which indicates X-Ray isn’t enabled. The e | |||
`Context` will be valid and sampled only if AWS X-Ray has been enabled for the Lambda function. A user can | |||
disable AWS X-Ray for the function if the X-Ray Span Link is not desired. | |||
|
|||
Instrumentation SHOULD include an explicit option to use `Context` in `_X_AMZN_TRACE_ID` as parent insted of `Link`, |
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.
Does the above paragraph also need to be modified to be "aware" of this configuration?
Co-authored-by: Daniel Dyla <dyladan@users.noreply.github.com>
Co-authored-by: Alex Boten <alex@boten.ca>
This change does not work for me. I have created #272 as an alternate proposal. |
@@ -66,6 +66,10 @@ contain an incomplete trace context which indicates X-Ray isn’t enabled. The e | |||
`Context` will be valid and sampled only if AWS X-Ray has been enabled for the Lambda function. A user can | |||
disable AWS X-Ray for the function if the X-Ray Span Link is not desired. | |||
|
|||
Instrumentation SHOULD include an explicit option to use `Context` in `_X_AMZN_TRACE_ID` as parent insted of `Link`, |
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.
Is it expected that instrumentations do anything special about X-Ray parents with unset sampled flag? If not, maybe a note could still be added that this may lead to all spans being unsampled unless X-Ray is enabled.
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.
Isn't that the case with any parent span context with an unset sampled flag? If so, that's something that should probably be addressed more broadly by the spec.
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.
Yes it is, but X-Ray is unusual in that you will get a valid unsampled span context if X-Ray is disabled.
FYI - TC discussion and opinion on this PR: #277 (comment) |
Closing this in favor of ongoing discussion in #354 |
This is done to offer compatibility to users with the previous behavior (which used the context in this X-Ray environment variable as the main parent).
Please review @open-telemetry/lambda-extension-approvers @dyladan @open-telemetry/python-maintainers
Note: I didn't include an actual name for this option, but I'm open to suggestions.
Closely related to open-telemetry/opentelemetry-js-contrib#1411