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

Allow create VirtualSegments with EndDate set manually (to support SNS->SQS fanout scenariou) #321

Closed
tsypuk opened this issue Jul 23, 2021 · 2 comments

Comments

@tsypuk
Copy link

tsypuk commented Jul 23, 2021

When event is sent to SNS from awslib wrapped with xray using WithContext, XRAY adds TraceHeader X-Amzn-Trace-Id.
Current it is not supported by AWS Lambda and xray library to automatically recover the TraceHeader and assign it as Parent SegmentID for the current Runtime (Lambda), etc. It is possible to recover trace header manually, create new Segment and assign TraceHeader SegmentID as ParentID for current segment. This will work for SQS integration and xray propagation scenario.

But in case if you are using SNS - to - SQS fanout: SNS propagates xray TraceHeader, but nor SNS nor SQS create Segment is XRAY. For such scenario it is possible to receive TraceHeader in SQS event. This TraceHeader is linked to SNS Service and its segments. SQS event contains information that can be used to create SQS Virtual segment (there is information in SQSEvent with metrics about both SNS and SQS timing, and based on them we can create exact startTime and endTime for SQS Virtual segment), map it to SNS pre-fanout Segment and fully recreate the trace chain. All further Segments in the current context will be mapped to SQS VirtualSegment.

The problem is that Xray lib automatically updates EndTime on Segment Close operation, which will make Time of VirtualSegment incorrect (with endTime set to NOW always).

Propose to automaticaly udpate EndTime only when it is not set, allowing to create Virtual segments for scenarios like SNS-SQS VirtualSegment fanout, etc.

@stale
Copy link

stale bot commented Jan 9, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs in next 7 days. Thank you for your contributions.

@stale stale bot added the stale label Jan 9, 2022
@willarmiros
Copy link
Contributor

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

No branches or pull requests

3 participants