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
WIP: Simple instrumentation with Jaeger backend #45962
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: gmarek Assign the PR to them by writing
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
9b81105
to
c0e347e
Compare
fca9cee
to
c1c8315
Compare
Only minor godep-related fixes are needed, I'll apply them tomorrow. |
b9da01f
to
859c350
Compare
@k8s-bot node e2e test this |
if r.ctx == nil { | ||
r.ctx = context.Background() | ||
} | ||
span, ctx := opentracing.StartSpanFromContext(r.ctx, fmt.Sprintf("%v %v", r.verb, r.resource)) |
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: this will create a bare bones span with little useful information. You may want to consider using https://github.com/opentracing-contrib/go-stdlib/ (or replicating that logic if you can do it more efficiently internally).
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.
It'd be way easier if there was a nethttp.NewFromTracer(tr *opentracing.Tracer, opts...) Tracer
function in the library... Currently I don't think it's worth the effort.
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.
if there was a nethttp.NewFromTracer(tr *opentracing.Tracer, opts...)
that's fair, my point is that a bare-bones span is not very useful when you actually want to troubleshoot some traces
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.
Do you think you can add such a function to the library?
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.
I had a look, the existing code there is too coupled. I think it's simpler to add the tags explicitly, rather than pull another dependency just for that. You want at least these:
ext.HTTPMethod.Set(span, req.Method)
ext.HTTPUrl.Set(span, req.URL.String())
ext.SpanKindRPCClient.Set(span)
ext.Component.Set(span, componentName) // optional
If you have the peer/callee address easily accessible, it's also useful to set
ext.PeerAddress.Set(span, address) // IP string or anything, really
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.
Added.
db4f638
to
ce6f6dc
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.
Main comment: this is a giant PR with the vendored code, etc... can you point me to the parts you are most concerned about / want feedback about from an OT standpoint?
I've made one tiny comment in the meantime. :)
Thanks!
} | ||
|
||
func startTracing(req *http.Request, operationName string) (otSpan opentracing.Span, simpleTrace *utiltrace.Trace) { | ||
trace := utiltrace.New(operationName) |
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.
I'm sure you considered it, but why not add an opentracing.Span field to utiltrace.Trace? Then you wouldn't need to pass them around together.
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.
I wanted to get rid of the old trace library, and I figured that this was was easier.
@bhs - only first three commits matter. Rest is generated code and godeps. |
@gmarek is this PR targeting 1.7? |
No, I don't think it is. |
span := opentracing.SpanFromContext(r.ctx) | ||
if span != nil { | ||
ext.HTTPMethod.Set(span, req.Method) | ||
ext.HTTPUrl.Set(span, req.URL.String()) |
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.
nit: reuse url
from above
span.Context(), | ||
opentracing.HTTPHeaders, | ||
opentracing.HTTPHeadersCarrier(req.Header)) | ||
} | ||
|
||
r.backoffMgr.Sleep(r.backoffMgr.CalculateBackoff(r.URL())) | ||
if retries > 0 { |
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.
what will happen if there are retries? The span seems to be created earlier, in the caller.
I saw this come in, but I'm prioritizing 1.7 items atm. |
@gmarek: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
@gmarek PR needs rebase |
I'm for dropping in favor of updated Events proposal. |
@timothysc @gmarek for those of us who are not k8s insiders, can you provide a pointer to the "Events" proposal? thanks. |
Sure, sorry - https://docs.google.com/a/google.com/document/d/13BeJlrEcJhSKgsHOHWmHdJGqXrjSm_o9XxOtwcN6yNg/edit?usp=sharing I also wanted to finish this work (there's not a lot to do), so we have tracing inside API server, but I didn't have time:( |
Ref. #26507
This adds OpenTracing instrumentation to the apiserver and client-go. It does all instrumentation work and only thing that's left to allow users using client-go instrumentation is allowing passing
context.Context
to client calls (@caesarxuchao @kubernetes/sig-api-machinery-feature-requests). Once this is done we'll need to write a short doc describing how to use this.cc @yurishkuro @bhs