-
Notifications
You must be signed in to change notification settings - Fork 69
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
tracing: add ExtractTraceSpanID #550
Conversation
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
CI is failing, checking if it has anything to do with this test Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
This reverts commit ab0f401.
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
tracing/tracing.go
Outdated
} | ||
|
||
return sctx.TraceID().String(), true | ||
return &sctx |
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.
By returning &sctx
, jaeger.SpanContext
needs to be allocated on a heap first, and then pointer to it returned, right?
Perhaps we could return just traceID and spanID directly? Or jaeger.SpanContext
without the pointer.
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 thought about that , but that (direct return) would be duplicated code. I can definitely do a copy of the jeager.SpanContext thought, if that's preferred?
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.
By the way , I don't know if the compiler is smart enough to avoid allocation on the heap
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.
Can we keep ExtractTraceID, and call ExtractTraceSpanID inside, just discard spanID when return result. In that case no need to refectory this extractJaegerContext but leave all logics in ExtractTraceSpanID
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.
facepalm, of course
although then your doing an extra string formatting call for the spanid
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 think it is a fair comment, current code LGTM, approved.
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 did inspire me to go ahead and look at the assembly :) Got the final result by deferring the formatting to the public function , but only returning the two relevant fields from the helper function. It's the least extra instructions.
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
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
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
What this PR does:
Add ExtractTraceSpanID helper function for enhanced logging.
Which issue(s) this PR fixes:
Related to grafana/mimir#8599
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]