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

Support AWS X-Ray #459

Closed
jramsdale opened this issue Dec 1, 2016 · 11 comments · Fixed by #829
Assignees
Milestone

Comments

@jramsdale
Copy link

@jramsdale jramsdale commented Dec 1, 2016

Much like Zipkin, Amazon now provides AWS X-Ray, their hosted tracing service: https://aws.amazon.com/xray/

Adding X-Ray support to Spring Cloud Sleuth would be a nice addition for users preferring to use AWS managed services.

@adriancole

This comment has been minimized.

Copy link
Contributor

@adriancole adriancole commented Dec 2, 2016

Here are some links of interest

description of data that can be sent: http://docs.aws.amazon.com/xray/latest/devguide/xray-api.html#xray-api-segments
the Api model: https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-models/src/main/resources/models/xray-2016-04-12-model.json
doesn't seem the servlet filter mentioned in docs is on github https://github.com/search?utf8=%E2%9C%93&q=AWSXRayServletFilter
here's an example of using their sdk http://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-java-subsegments.html

Here's some notes @ryangardner toook at reinvent

A few tidbits from talking to the amazon people about their implementation. One reason they went with their own stuff was because they felt they needed to put the timing stuff in the header to make it easier to scale it up
They shuttle the data over UDP to a daemon that runs on localhost and that daemon sends it to the collector. It’s a well-known endpoint that everyone in AWS will share for a given region. The data you see is based on the account you send the data in from. If you want to trace data across multiple aws accounts you have to use a cross-account linking and assuming the role of the central “x-ray” account for your org. In the future they may be able to make this easier by leveraging metadata made available by the “orgs” feature that amazon just announced

@adriancole

This comment has been minimized.

Copy link
Contributor

@adriancole adriancole commented Dec 2, 2016

so I think next step would be either get a hold of the instrumentation SDK code and/or a spec for how headers propagate, etc. Particularly, if this is related to and/or compatible with the recent announcement on ALB, which seems to imply "cookie crub" trace id header. Ex ids are tacked on.

@nicmunroe

This comment has been minimized.

Copy link

@nicmunroe nicmunroe commented Dec 2, 2016

I took a quick look at this yesterday for Wingtips. The docs are sort of broken with how to pull in libs, where classes are, etc. But I did find the AWSXRayServletFilter class. It's in this dependency: com.amazonaws:aws-xray-recorder-sdk-core:1.0.0-beta. The source jar had no java code in it though, so it's basically fun with decompiled code.

In particular, a bunch of info is propagated with a X-Amzn-Trace-Id header. I think trace ID, "segment" (span) ID, parent ID, and sampled are embedded in that one header value.

There also looks to be several magic attributes you can add to the segment/span tags/metadata - I'm assuming the AWS tools will do useful things with those.

I'm not sure what a meaningful integration or support of XRay looks like in relation to other instrumentation libraries like spring sleuth/zipkin/etc or what it accomplishes. Feels like there should be some good use cases here somewhere, just not sure what they are yet.

@davidnortonjr

This comment has been minimized.

Copy link

@davidnortonjr davidnortonjr commented Jan 2, 2017

perhaps an alternative to the X-Ray daemon would be a Zipkin-compatible service, that translates the Zipkin traces and publishes to X-Ray using the AWS SDK? Similar in concept to Stackdriver Trace's Zipkin integration:

https://github.com/GoogleCloudPlatform/stackdriver-zipkin

This would allow AWS storage/retrieval of trace data while using the Zipkin header standards and the superior Zipkin client libraries - a big problem with X-Ray currently is that it only supports a few frameworks on a few platforms.

@adriancole

This comment has been minimized.

Copy link
Contributor

@adriancole adriancole commented Jan 25, 2017

ps detailed docs were just published about X-Ray's out-of-band format http://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html

@hakanson

This comment has been minimized.

Copy link

@hakanson hakanson commented Feb 11, 2017

FYI - until they release the Java source, you can npm install aws-xray-sdk and get the JavaScript version of the source code to look through. I had been digging though that code when I was porting a sample app from zipkin-js to x-ray and trying to wrap/patch node-fetch (see https://forums.aws.amazon.com/thread.jspa?threadID=247252&tstart=0).

@adriancole

This comment has been minimized.

Copy link
Contributor

@adriancole adriancole commented Feb 12, 2017

@chenrui333

This comment has been minimized.

Copy link

@chenrui333 chenrui333 commented Jun 7, 2017

+1

1 similar comment
@howardem

This comment has been minimized.

Copy link

@howardem howardem commented Jun 29, 2017

+1

@metaruslan

This comment has been minimized.

Copy link

@metaruslan metaruslan commented Jul 28, 2017

Hi guys, did you have any luck in getting the java source code from x-ray? I did ask them and waiting now
https://forums.aws.amazon.com/thread.jspa?threadID=260671&tstart=0

adriancole added a commit that referenced this issue Oct 5, 2017
Amazon will throw out trace IDs that aren't associated with a recent
timestamp. This encodes the current epoch seconds into the first 32
of a 128-bit trace ID to support conversion to an Amazon Root ID.

See #459
adriancole added a commit that referenced this issue Oct 6, 2017
This adds the ability to opt out of span sharing between the client and
server side of an RPC. This is important when reporting to systems that
do not share span IDs, such as Google Stackdriver and Amazon X-Ray.

Note: this still defaults to true, in favor of existing Zipkin
implementations. See openzipkin/zipkin#1480

See #395
See #459
@andrewpowell

This comment has been minimized.

@marcingrzejszczak marcingrzejszczak added this to the 2.0.0.M6 milestone Jan 19, 2018
@marcingrzejszczak marcingrzejszczak self-assigned this Jan 19, 2018
marcingrzejszczak added a commit that referenced this issue Jan 19, 2018
with this pull request we have rewritten the whole Sleuth internals to use Brave. That way we can leverage all the functionalities & instrumentations that Brave already has (https://github.com/openzipkin/brave/tree/master/instrumentation).

Migration guide is available here: https://github.com/spring-cloud/spring-cloud-sleuth/wiki/Spring-Cloud-Sleuth-2.0-Migration-Guide

fixes #711 - Brave instrumentation
fixes #92 - we move to Brave's Sampler
fixes #143 - Brave is capable of passing context
fixes #255 - we've moved away from Zipkin Stream server
fixes #305 - Brave has GRPC instrumentation (https://github.com/openzipkin/brave/tree/master/instrumentation/grpc)
fixes #459 - Brave (openzipkin/brave#510) & Zipkin (openzipkin/zipkin#1754) will deal with the AWS XRay instrumentation
fixes #577 - Messaging instrumentation has been rewritten
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.