-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
Add otel tracing #45652
Add otel tracing #45652
Conversation
cpuguy83
commented
May 30, 2023
- Adds basic otel instrumentation to http transports/handlers
- Adds OTLP/HTTP exporter
- Updates tests to configure traces/spans automatically (as automatically as we can, anyway)
- Exposes options in Makefile to pass through info needed to export traces from test daemon
2537a93
to
9cc176d
Compare
be86f14
to
831d6cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested this and it now logs "no trace recorder found, skipping" for every build. It happens because detect.Exporter()
returns nil.
(This can be a follow-up as not directly related, but) I don't think client-side traces can work unless TraceCollector
is set in control.NewController(control.Opt{
29020a4
to
5272256
Compare
HistoryConfig: historyConf, | ||
LeaseManager: wo.LeaseManager, | ||
ContentStore: wo.ContentStore, | ||
TraceCollector: getTraceExporter(ctx), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the client trace delegation still doesn't work yet, but the issue is in buildx side where it is not enabled for all drivers. I'll make a patch for this tomorrow. Moby side looks correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
had a discussion in the maintainers call;
- the integration tests already set the SERVICE_NAME (so for our own tests, it's not an issue to remove the daemon iD)
- the current code moved "generating" the daemon-id only for OTEL (not ideal)
- let's remove the ID for now, and work on other options in a follow-up
after that, "LGTM" (let's get this in!)
This uses otel standard environment variables to configure tracing in the daemon. It also adds support for propagating trace contexts in the client and reading those from the API server. See https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/ for details on otel environment variables. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Integration tests will now configure clients to propagate traces as well as create spans for all tests. Some extra changes were needed (or desired for trace propagation) in the test helpers to pass through tracing spans via context. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This wires up the integration tests to export spans to a jager instance. After tests are finished it exports the data out of jaeger and uploads as an artifact to the action run. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This test ensures that we are able to propagate traces into buildkit's history API. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Updated and all is green. |
w000000000t! thank so much for this, @cpuguy83 ! |
@cpuguy83 I assume you'll be opening the GHA followup PRs? |
Now that this one's merged, I rebased, moved this one out of draft 😅 (wink wink, nudge nudge, say no more) |
Since moby/moby#45652, client.NewClientWithOpts wraps its Transport with otelhttp.NewTransport, but *otelhttp.Transport doesn't satisfy http.Transport. Fixes #3274
Since moby/moby#45652, client.NewClientWithOpts wraps its Transport with otelhttp.NewTransport, but *otelhttp.Transport doesn't satisfy http.Transport. Fixes #3274