-
Notifications
You must be signed in to change notification settings - Fork 5.4k
skywalking: inject peer IP address into span's peer field #20454
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
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -39,6 +39,12 @@ void Span::setSampled(bool do_sample) { | |
|
|
||
| void Span::log(SystemTime, const std::string& event) { span_entity_->addLog(EMPTY_STRING, event); } | ||
|
|
||
| void Span::setStreamInfoIntoSpan(const StreamInfo::StreamInfo& stream_info) { | ||
| if (stream_info.upstreamInfo() && stream_info.upstreamInfo()->upstreamHost()) { | ||
| span_entity_->setPeer(stream_info.upstreamInfo()->upstreamHost()->address()->asString()); | ||
| } | ||
| } | ||
|
Comment on lines
+42
to
+46
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This The peer address of Entry Span should be the downstream address, right? And the peer address of Exit Span should be the upstream address. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The peer of exit span is the key. The entry span's is optional actually.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then, the peer address of Exit Span should be the upstream address, is that right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it is correct.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @wu-sheng Get it, thanks.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Shikugawa based on the above discussions, may be we can complete the peer address injection of Exit Span directly in the #20367. We can inject the downstream address of the Entry Span here if you think it's necessary. But it should be unnecessary, because Envoy will set peer address tag for the downstream span.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this is good to set peer address in exit span in void setStreamInfo(const StreamInfo::StreamInfo& stream) {
if (span_entity_->spanType() == Entry) {
span_entity_->setPeer(tream_info.downstreamAddressProvider().directRemoteAddress()->addressAsString());
} else {
span_entity_->setPeer(tream_info.upstreamInfo()->upstreamHost()->address()->asString());
}
}And calls
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for your reply. My hope is that this can be done with minimal code modification, minimal performance overhead, and avoiding duplicate field settings. If we had done this directly in #20367, the most critical exit span peer injection might have been done with just one extra line of code. And there is no need to repeatedly obtain the upstream host from stream info, and the performance will be slightly better. The method name doesn't really matter. Because peer of exit span is a unique concept of skywalking, it is unknown to the caller of the virtual method. So we only need to do this work in any suitable method implementation. However, this is only my personal opinion after all, it is only for reference. As long as the implementation is clean and correct, we can find another relevant maintainer to review the PR, and his review opinion shall prevail. 😸
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since these operations have nothing to do with Header Injection, they complicate the code on the SkyWalking side. In addition, the performance impact of such operations is negligible. So I think I should define There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The entry span's operation does. The parent endpoint in the header is the entry span's operation name(path). |
||
|
|
||
| void Span::finishSpan() { | ||
| span_entity_->endSpan(); | ||
| parent_tracer_.sendSegment(tracing_context_); | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.