Fix distributed tracing #28
Conversation
| /** | ||
| * Finish the active span. If you have installed the dd-trace-java Lambda | ||
| * layer, you MUST call DDLambda.finish() at the end of your Handler | ||
| * in order to finish spans. |
There was a problem hiding this comment.
In the other libraries, we are able to run code automatically at the end of the function execution to finish the span (and do other stuff, like send enhanced metrics). Is it not possible to do that in Java as well? I think requiring customers to do it manually could potentially lead to confusion.
There was a problem hiding this comment.
That's on the table for future improvements, but it's difficult to implement right now. Much more so than in interpreted languages [1]. One strategy we're looking into is potentially porting this logic into dd-agent-java (since that is already doing a lot of reflective stuff to decorate other classes), but we have some concerns about being beholden to dd-agent-java's release cycle. TBD.
[1]and, weirdly, the way Go has implemented reflection makes it a lot easier to wrap a Go handler than a Java handler.
There was a problem hiding this comment.
I do agree that ideally we would have an @decorator added to a handler function, but I think this compromise is okay for now.
| import io.opentracing.Scope; | ||
| import io.opentracing.SpanContext; | ||
| import io.opentracing.Tracer; | ||
| import io.opentracing.Tracer.SpanBuilder; |
There was a problem hiding this comment.
If a user hasn't installed the agent, do the open tracing libs have any effect on performance?
There was a problem hiding this comment.
I suspect the difference is sub-millisecond, but I'll verify that.
There was a problem hiding this comment.
OK, confirmed. The difference between the two isn't significant.
| /** | ||
| * Finish the active span. If you have installed the dd-trace-java Lambda | ||
| * layer, you MUST call DDLambda.finish() at the end of your Handler | ||
| * in order to finish spans. |
There was a problem hiding this comment.
I do agree that ideally we would have an @decorator added to a handler function, but I think this compromise is okay for now.
What does this PR do?
This provides methods for getting the datadog trace and span ID from incoming request headers and setting them inside dd-agent-java attached to the JVM. Specifically:
startSpan.startSpanuses the OpenTracing API to communicate with dd-agent-java to start a new span. If the appropriate headers are set on the request,startSpanpackages that information in such a way that dd-agent-java can read the headers and set the traceID and parentID on that span.finish, which stops the active span and closes the tracer scope opened bystartSpan.finishis a noop if no span has been started. For the time being, users still must instantiate anew DDLambda([request, ]context)in order to start a span and callDDLambda.finish()in order to finish the span.checkTraceEnabledfunction that checks the environment variables to see if the user has setDD_TRACE_ENABLEDto true or not.I'm intentionally not updating the README since we're keeping the dd-agent-java lambda layer private for now. Will update the README with documentation once we choose to GA dd-agent-java.
Does not include logic to merge x-ray traces yet.
Motivation
Testing Guidelines
Additional Notes
Types of changes
Checklist