-
Notifications
You must be signed in to change notification settings - Fork 484
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
DDG: Remove kind.server filter and validate the case of service calling itself #557
Conversation
Still need to fix some tests. |
7f0ca32
to
0de01ca
Compare
Codecov Report
@@ Coverage Diff @@
## master #557 +/- ##
==========================================
- Coverage 92.90% 92.88% -0.02%
==========================================
Files 200 200
Lines 4917 4935 +18
Branches 1213 1219 +6
==========================================
+ Hits 4568 4584 +16
- Misses 309 311 +2
Partials 40 40
Continue to review full report at Codecov.
|
dfd4838
to
468a9d7
Compare
if (reducedSpans.length > 0) { | ||
const headSpan = reducedSpans[reducedSpans.length - 1]; | ||
// Transition inside the same service ServiceA -> ServiceA | ||
if (headSpan.processID === span.processID) { |
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.
@rubenvp8510 sorry I couldn't get to this sooner
If I'm reading this correctly, it captures every change in processID
. Then, if there isn't a change in processID
and the current span is of kind server
:
- a parent
client
span that was a different process than its parent span gets replaced with theserver
span - a parent
server
span is kept and the current span is added.
I'm wondering if we need to do the replacement in case 1, or if it would be better to simply add any span of kind server
or any span with a different processID
than the previous reduced span.
i.e.:
if (headSpan.processID !== span.processID || isKindServer(span) {
reducedSpans.push(span);
}
The only case this is different is if process a
calls process b
which emits a client
span as its first span, which is the parent of a server
span in the same process. IMO this case is strange, possibly caused by bad instrumentation, and I'd prefer to surface the scenario to potentially fix it rather than bury it.
@yurishkuro @vprithvi I'd like to hear your opinions on the two approaches to handling this case.
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.
@rubenvp8510 Update: I have discussed the two approaches with Yuri and Prithvi and we agree to not replace the ingress client spans.
Here's an example, which, for brevity, I will represent a single span as processID,operationName,[s]erver/[c]lient
e.g.:
{
processID: 0,
operationName: 'a',
span.kind: 'client',
}
would be 0,a,c
original:
0,a,c 1,a,s 1,b,c 1,c,s, 2,a,c, 2,b,s 2,c,c
would be reduced to
0,a,c 1,a,s 1,c,s 2,a,c 2,b,s
by my proposed method
versus
0,a,c 1,a,s 1,c,s 2,b,s
in the PR
The differences is that the client ingress span (2,a,c
) is not dropped.
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.
Hi @everett980 I think it is OK not loses the ingress client span. it just wasn't clear to me what would be the correct way of derivative the paths on those cases, but now it makes more sense. I'll do the pertinent changes.
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 did the changes, this is ready for another review.
Thank you!
Signed-off-by: Ruben Vargas <[email protected]>
Signed-off-by: Ruben Vargas <[email protected]>
Signed-off-by: Ruben Vargas <[email protected]>
Signed-off-by: Ruben Vargas <[email protected]>
This also fixes #546 I added a test for that case. |
Signed-off-by: Ruben Vargas <[email protected]>
reducedSpans.push(span); | ||
} else if ( | ||
reducedSpans[reducedSpans.length - 1].processID !== span.processID || | ||
isKindServer(span) |
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 whole algorithm expressed in these two lines, awesome!
cc @vprithvi
Signed-off-by: Ruben Vargas <[email protected]>
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.
@rubenvp8510 looks good! One minor nit and then it's good to go.
@@ -52,7 +60,7 @@ describe('transform traces to ddg paths', () => { | |||
(result, span) => ({ | |||
...result, | |||
[span.processID]: { | |||
serviceName: `${span.spanID.split(' ')[0]} service`, | |||
serviceName: span.processID, |
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 doesn't fully test that the serviceName
s are populated. change this to
serviceName: ${span.processID}-name,
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.
Done.
Thanks for the review!
Signed-off-by: Ruben Vargas <[email protected]>
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, thanks for tackling this!
…ng itself (jaegertracing#557) * DDG: Remove kind.server filter and handle service calling itself * Improve tests on transformTracesToPath * Preserve (do not replace) client ingress spans * Add test for root client span * Improve DDG paths algorithm * Use TREE_ROOT_ID on transformTracesToPaths function * Change makeTrace to set service name to [spanID]-name Signed-off-by: Ruben Vargas <[email protected]> Signed-off-by: vvvprabhakar <[email protected]>
Which problem is this PR solving?
Short description of the changes
Attached an image.