contrib/internal/httptrace: add support for inferred proxy spans#3052
Conversation
zarirhamza
left a comment
There was a problem hiding this comment.
Needs a bit of cleanup and logging for prod but logically looks good. Going to request @wantsui to look at it as well to confirm the span information is relatively similar as in dd-trace-js.
BenchmarksBenchmark execution time: 2025-01-22 22:12:35 Comparing candidate commit 39087f1 in PR branch Found 0 performance improvements and 3 performance regressions! Performance is the same for 55 metrics, 1 unstable metrics. scenario:BenchmarkStartRequestSpan-24
|
|
Let's also make sure that we test that our inferred span matches the behavior of the parent span by asserting things like that status code are the same |
…W spans via headers Function checks for existence of AWS APIGW headers and infers proxy span if necessary Updates usage in all contribs that implement function Updates test usage that implement function
Datadog ReportBranch report: ✅ 0 Failed, 5207 Passed, 72 Skipped, 2m 19.94s Total Time |
|
@zarirhamza @jordan-wong Do you know why the benchmarks are reporting this 50%+ increase in execution time in BenchmarkStartRequestSpan? 🟥 execution_time [+159.899ns; +160.941ns] or [+52.326%; +52.667%] |
| spanParentCtx, spanParentErr := tracer.Extract(tracer.HTTPHeadersCarrier(r.Header)) | ||
| spanLinksCtx, spanLinksOk := spanParentCtx.(ddtrace.SpanContextWithLinks) |
There was a problem hiding this comment.
@zarirhamza @jordan-wong I think this unconditional extraction of spanParentCtx is the source of the performance impact.
Would it be possible to isolate everything related to the inferred proxy spans so it runs if the feature is activated?
There was a problem hiding this comment.
Previously, the span extraction would happen on every call anyway just within the span option func. I tried isolating all behaviors as much as possible so that should improve the performance.
There was a problem hiding this comment.
Also unsure if the fact we now have cleanup functions via StartRequestSpans may result in increased usage that is expected solely due to behavior
darccio
left a comment
There was a problem hiding this comment.
Looks like the increased CPU time and memory are to be expected due to the new implementation.
What does this PR do?
This PR introduces functionality to infer proxy spans based on headers that we instruct users to inject upstream, allowing these headers to be propagated downstream. The headers are then used to infer a proxy span to provide increased visibility to a user's trace. The headers are as follows:
x-dd-proxyaws-apigatewayaws-apigatewayx-dd-proxy-request-time-mscontext.requestTimeEpochx-dd-proxy-domain-namecontext.domainNamex-dd-proxy-httpmethodcontext.httpMethodx-dd-proxy-pathcontext.pathx-dd-proxy-stagecontext.stageMotivation
There is no current support for API Gateway and other proxies that do not run Datadog code. By inferring spans via headers, the gaps in observability can be filled to provide a more accurate trace.
Reviewer's Checklist
v2-devbranch and reviewed by @DataDog/apm-go.Unsure? Have a question? Request a review!