Add tracing for incoming requests #101
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
charleskorn
force-pushed
the
charleskorn/tracing
branch
4 times, most recently
from
bd40382
to
3243a6b
Compare
charleskorn
force-pushed
the
charleskorn/tracing
branch
from
3243a6b
to
cb751db
Compare
jhalterman
reviewed
Jan 9, 2024
jhalterman
approved these changes
Jan 10, 2024
Note that Kubernetes API calls made here are not traced because they are not made using the context with the span attached.
…s in prepare downscale webhook
charleskorn
force-pushed
the
charleskorn/tracing
branch
from
1c9537a
to
40b463c
Compare
56quarters
approved these changes
Jan 10, 2024
|
|
||
| spanLogger.SetTag("object.name", ar.Request.Name) | ||
| spanLogger.SetTag("object.resource", ar.Request.Resource.Resource) | ||
| spanLogger.SetTag("object.namespace", ar.Request.Namespace) | ||
|
|
||
| oldObj, oldGVK, err := codecs.UniversalDeserializer().Decode(ar.Request.OldObject.Raw, nil, nil) | ||
| if err != nil { | ||
| return allowErr(logger, "can't decode old object, allowing the change", err) | ||
| } | ||
| logger = log.With(logger, "request_gvk", oldGVK) |
There was a problem hiding this comment.
I appreciate trying to minimize changes but it seems weird to use both logger and spanLogger. Can we use just the spanLogger and not keep logger around in these methods?
andyasp
added a commit
that referenced
this pull request
Jan 10, 2024
|
Apologies @charleskorn, I merged too early. I reverted the commit and restored the branch so you could respond to the above in a reopened PR. |
No worries, I'll continue in #114. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for tracing incoming HTTP requests for the two webhooks.
It produces traces like the following, with nested spans for each of the HTTP calls:
I've used OpenTracing here over OpenTelemetry in the interests of consistency with Mimir.
I don't love how invasive these changes were - the default OpenTracing instrumentation for
net/httprequires callingnethttp.TraceRequest()for each outgoing HTTP call, but any other option would require either creating our own OpenTracing instrumentation fornet/http, or using OpenTelemetry, which would break with the existing pattern of Mimir. I'm very open to other ideas or suggestions.I don't believe we can't add tracing for Kubernetes API calls made by the informers used in the reconciliation loop, as these run outside the context of a parent span, so I haven't added tracing to the reconciliation loop beyond a single span.