Skip to content
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

Merged
merged 7 commits into from
Apr 24, 2020

Conversation

rubenvp8510
Copy link
Collaborator

Which problem is this PR solving?

Short description of the changes

  • I removed the span.kind == server filter, instead validate when the service calls itself multiple times and remove all of those recursive calls and only preserve one of them.

Attached an image.

Screenshot from 2020-04-04 09-35-55

@rubenvp8510
Copy link
Collaborator Author

Still need to fix some tests.

@rubenvp8510 rubenvp8510 changed the title DDG: Remove kind.server filter and handle service calling itself DDG: Remove kind.server filter and validate the case of service calling itself Apr 4, 2020
@rubenvp8510 rubenvp8510 changed the title DDG: Remove kind.server filter and validate the case of service calling itself [WIP] DDG: Remove kind.server filter and validate the case of service calling itself Apr 5, 2020
@rubenvp8510 rubenvp8510 changed the title [WIP] DDG: Remove kind.server filter and validate the case of service calling itself DDG: Remove kind.server filter and validate the case of service calling itself Apr 6, 2020
@rubenvp8510 rubenvp8510 force-pushed the Issue-554 branch 4 times, most recently from 7f0ca32 to 0de01ca Compare April 14, 2020 17:53
@codecov
Copy link

codecov bot commented Apr 14, 2020

Codecov Report

Merging #557 into master will decrease coverage by 0.01%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            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              
Impacted Files Coverage Δ
...jaeger-ui/src/model/ddg/transformTracesToPaths.tsx 100.00% <100.00%> (ø)
packages/jaeger-ui/src/utils/TreeNode.js 100.00% <100.00%> (ø)
...eViewer/TimelineHeaderRow/TimelineViewingLayer.tsx 88.13% <0.00%> (-3.39%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4c8fc98...0b3bf0c. Read the comment docs.

@rubenvp8510 rubenvp8510 force-pushed the Issue-554 branch 3 times, most recently from dfd4838 to 468a9d7 Compare April 15, 2020 18:31
if (reducedSpans.length > 0) {
const headSpan = reducedSpans[reducedSpans.length - 1];
// Transition inside the same service ServiceA -> ServiceA
if (headSpan.processID === span.processID) {
Copy link
Collaborator

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:

  1. a parent client span that was a different process than its parent span gets replaced with the server span
  2. 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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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!

@rubenvp8510
Copy link
Collaborator Author

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)
Copy link
Member

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

Copy link
Collaborator

@everett980 everett980 left a 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,
Copy link
Collaborator

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 serviceNames are populated. change this to

serviceName: ${span.processID}-name,

Copy link
Collaborator Author

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!

Copy link
Collaborator

@everett980 everett980 left a 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!

@everett980 everett980 merged commit 2a0321e into jaegertracing:master Apr 24, 2020
vvvprabhakar pushed a commit to vvvprabhakar/jaeger-ui that referenced this pull request Jul 5, 2021
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DDG for search results is still wrong
3 participants