-
Notifications
You must be signed in to change notification settings - Fork 431
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
Percolate Azure correlation IDs to REST API calls #1574
Conversation
Hi @arschles. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
// Wrap the original Sender on the autorest.Client c. | ||
// The wrapped Sender should set the x-ms-correlation-id on the given | ||
// request, then pass the new request to the underlying Sender. | ||
c.Sender = autorest.DecorateSender(c.Sender, msCorrelationIDSendDecorator) |
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.
@devigned related to our (offline) discussion today - you pointed out that autorest client creation code is centralized around this function. I this just wraps (wraps! 😆) the raw client's sender in code that extracts the correlation ID out of the request context, puts it into the header, and then calls through to the underlying sender. I think this does the trick. See below for a related comment on tests.
@@ -235,3 +240,51 @@ func TestGetDefaultUbuntuImage(t *testing.T) { | |||
}) | |||
} | |||
} | |||
|
|||
func TestMSCorrelationIDSendDecorator(t *testing.T) { |
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.
@CecileRobertMichon @devigned would you prefer that I include a test here for SetAutoRestClientDefaults
rather than just msCorrelationIDSendDecorator
. I didn't want to blow up the scope too much, but I'm happy to go a bit bigger in tests here if you'd prefer.
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.
this is fine with me, ideally we would add both but for this specific functionality a specific test is good enough
5795c49
to
f5d003c
Compare
f5d003c
to
71d2e59
Compare
a6a5671
to
a07f5b1
Compare
/ok-to-test |
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.
/assign @mboersma
@arschles sorry for the delay getting back to you on this. The PR looks good to me, are you planning to make the required changes to all controllers in the PR? I've asked @mboersma for a review as well. The tests are failing because of lint:
|
@CecileRobertMichon not a problem.
Great to hear. The changes in those controllers were unnecessary, so I've removed them in 9a04ee4 (I'll squash later so you can see that in isolation for now). My apologies for forgetting to take those changes out.
Great, and howdy @mboersma!
Fixed in 86ab113 |
/retest |
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.
The PR lgtm. @arschles, let's pair for a minute to verify the correlation ID is being propagated and collected in ARM.
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.
Looks good.
I'll try this in tilt
locally to see if I can spot the Correlation ID being propagated.
The observability "stack" continues to work with this change, but I can't tell by looking at the traces (in Jaeger or in App Insights) if Deferring to @devigned... |
We need to validate that we can find a correlation ID in ARM logs. @arschles let's verify and then I'm good. |
@devigned k, I'll contact you offline and we can set up a time to do this verification 😄 |
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.
Overall looks solid. However, upon verifying the correlation ID in ARM logs, I was unable to find the correlated HTTP requests. After changing the HTTP header key, I was able to find the correlated HTTP request.
I think it would be important to also add the correlation ID to the span to make it easier for users to report correlated Azure requests via a trace attribute. This will make it much easier for a support rep to debug what is happening on the Azure side of things.
util/tele/tele.go
Outdated
@@ -36,6 +36,7 @@ func (t tracer) Start( | |||
opts ...trace.SpanOption, | |||
) (context.Context, trace.Span) { | |||
ctx, _ = ctxWithCorrID(ctx) | |||
opts = append(opts, trace.WithSpanKind(trace.SpanKindClient)) |
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.
Please consider adding the correlation ID to the span as well. That way, the traces will also have an ARM correlation ID available.
Signed-off-by: Aaron Schlesinger <[email protected]>
43ca6eb
to
3640e00
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.
/lgtm
pending tests for approval
@CecileRobertMichon do you have any comments? If not, I've verified the functionality and lgtm. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: CecileRobertMichon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@CecileRobertMichon @devigned @mboersma thank you all for your help on this PR! |
/kind feature
What this PR does / why we need it:
This is a follow-on to #1460. In that PR, we added functionality to set
x-ms-correlation-id
keys on allcontext.Context
s returned by new traces returned bytele.Tracer().Start()
. That change ensured that correlation IDs were created at the root of all reconciliation operations, but those correlation IDs did not escape the running process. This change ensures that, as the correlation IDs percolate to the REST API/autorest
layer, they are picked up and sent over the wire to the Azure API.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1310
Special notes for your reviewer:
This is a follow-on PR to #1460, according to this comment. It should not be merged before that one. I am submitting this as a draft pull request until #1460 is merged.
@CecileRobertMichon @devigned there are 2 things that we've discussed that should be done after #1460:
I'll submit the second in a separate PR
TODOs:
Release note: