Skip to content
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

lambda: use _X_AMZN_TRACE_ID trace context as a Link not parent #3428

Closed
wants to merge 1 commit into from

Conversation

tsloughter
Copy link
Member

@tsloughter
Copy link
Member Author

Note that xrayEventToCarrier in xrayconfig.go now does nothing. This is because it only read the environment variable before and since that now is for a Link it had to be removed, leaving it doing nothing.

Another option is to remove xrayconfig/ entirely, instead of leaving essentially dead code that is waiting for features to be added to do something.

@tsloughter tsloughter force-pushed the lambda-xray-env branch 5 times, most recently from 6037833 to 05b949c Compare February 24, 2023 22:38
func xrayEventToCarrier([]byte) propagation.TextMapCarrier {
xrayTraceID := os.Getenv("_X_AMZN_TRACE_ID")
return propagation.HeaderCarrier{"X-Amzn-Trace-Id": []string{xrayTraceID}}
return propagation.HeaderCarrier{}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this change is necessary. This package provides a set of helpers for configuring the Lambda instrumentation with opinionated defaults, but is not required to use the instrumentation. Leaving it as-is can minimize the impact to users who already have a working setup with these defaults while still having the expected linking behavior.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But having this become the parent was part of the confusion people were seeing that led to changing it to a link.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support removing the _X_AMZN_TRACE_ID environment variable reference here because it doesn't conform to the updated spec.

Eventually this code should be updated to actually provide a carrier from the input, but I don't think that should preclude removing the environment variable usage.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not the Lambda instrumentation and does not need to conform to any specification. It is a helper provided to make it easier for users to have an experience that aligns with that of using X-Ray.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is lambda specific. If it continued to extract the environment variable then there would have to be a new eventToCarrier created to handle lambda events and ignore the environment variable and this one would be unused?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Aneurysm9 can this be resolved?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend that we not remove this functionality, but should remove it from the WithRecommendedOptions.

There are two reasons I see for this change to the PR:

  1. This allows a path for current users to keep current functionality.
  2. There does seem to be a missing propagation here. I'm not fluent enough if X-Ray to know what should be in the X-Amzn-Trace-Id header (would the local trace-id and span id work?) but it would seem without it all requests made would be orphaned.

@@ -56,6 +57,23 @@ func newInstrumentor(opts ...Option) instrumentor {
resAttrs: []attribute.KeyValue{}}
}

func xrayEnvToLinks() []trace.Link {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is idiomatic to return a list of one item or an empty list.

In some languages I'd definitely do it this way, in others I'd return null and others I'd return a Maybe Link, with WithLinks accepting those.

Returning nil or *trace.Link felt off (especially since I didn't see a way to not have to do one start in the first branch of if link != nil and another in the else branch), but maybe that is the way to go to avoid an unnecessary creation of an empty list?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants