Trace HTTPClient request execution #320
Conversation
|
Can one of the admins verify this patch? |
4 similar comments
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
Can one of the admins verify this patch? |
|
I chatted with @ktoso earlier to discuss the manual context propagation, and we agreed that we probably shouldn't deprecate the "old" API accepting a |
There was a problem hiding this comment.
So since technically we're 0.1 and something may change... how do we want to tackle adoption here.
I was thinking to kick off a branch like tracing for now, so we can polish up there and once we're all confident merge into mainline? We could also tag those tracing releases, they'd follow normal releases e.g. 1.2.2-tracing.
I don't really expect anything breaking in the core APIs but the open telemetry support which we may want to use here could still fluctuate a little bit until they're final hmmm...
Package.swift
Outdated
| ], | ||
| targets: [ | ||
| .target( | ||
| name: "AsyncHTTPClient", | ||
| dependencies: ["NIO", "NIOHTTP1", "NIOSSL", "NIOConcurrencyHelpers", "NIOHTTPCompression", | ||
| "NIOFoundationCompat", "NIOTransportServices", "Logging"] | ||
| "NIOFoundationCompat", "NIOTransportServices", "Logging", "Instrumentation"] |
There was a problem hiding this comment.
Can we right away go with Tracing and do the full thing in a single PR?
There was a problem hiding this comment.
That's my intention. I've added a checklist to the PR including creating a Span. I first wanted to get the instrumentation part down and then continue with tracing, but all inside this PR.
slashmo
force-pushed
the
feature/tracing
branch
2 times, most recently
from
047fbb0 to
87085d9
Compare
|
@swift-server-bot add to whitelist |
|
I'd like to punt this to a side-branch for iterative development if we can. |
Sure, sounds like a good approach. I can change the target branch once it's created. |
|
I've opened up the |
|
@ktoso The CI seems to fail because the Baggage repo cannot be cloned through the Git URL. Should we pin Tracing to 0.1.1 here in order to get the fix? (apple/swift-distributed-tracing/pull/25) |
|
No, we need to tag a 0.1.1, I'll do that in a moment. |
|
0.1.1. tagged, please depend on that. Thanks Cory for the development branch, sounds good 👍 |
slashmo
force-pushed
the
feature/tracing
branch
from
87085d9 to
ae7268d
Compare
|
@swift-server-bot test this please |
|
Can drafts get CI validation? 🤔 |
|
Yes, they can: I think the CI isn't targeting that branch at the moment. |
slashmo
force-pushed
the
feature/tracing
branch
from
ae7268d to
329522c
Compare
slashmo
force-pushed
the
feature/tracing
branch
from
329522c to
d68cb8f
Compare
slashmo
force-pushed
the
feature/tracing
branch
from
e6e48ef to
5e7ddf1
Compare
Motivation:
Context Propagation
In order to instrument distributed systems, metadata such as trace ids
must be propagated across network boundaries through HTTP headers.
As HTTPClient operates at one such boundary, it should take care of
injecting metadata into HTTP headers automatically using the configured
instrument.
Built-in tracing
Furthermore,
HTTPClientshould create aSpanfor executed requestsunder the hood, so that users benefit from tracing effortlessly.
Modifications:
Spanfor executed HTTP requestResult:
AsyncHTTPClientautomatically creates a Distributed Tracing span per requestAsyncHTTPClientpropagates service context to server, making server spans children of client spans