-
Notifications
You must be signed in to change notification settings - Fork 506
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
Compare of two trace instances showing diff at wrong point #252
Comments
@objectiser thanks for reporting this. The spans for The current treatment is intentional, but may not be correct. A bit of contextSpans are first grouped within a trace to simplify and condense the representation, and then the condensed traces are compared. This is how nodes in the comparison DAG have numbers of spans associated with them. When condensing a trace, two spans are in the same group iff:
When comparing a trace, the same heuristic is used to match groups of spans. A group of spans from trace A is matched with a group of spans from trace B iff:
Options for creating groupsGiven the following trace, with A being the root node:
More denseI believe the approached you described is achived by removing the second grouping condition and would result in the following structure:
Where the DenseThe current implementation would result in:
Less denseThere is the possibility of changing the second grouping condition to:
And, would result in the following:
The two B nodes which are parents are not combined because they do not have the same set of children. Which is correct?I think "correct" is defined by which is most useful. We discussed it internally and settled on the "dense" variation. But, it's arbitrary. The "less dense" variation preserves the structure of the trace with the most authenticity, but the more separated elements are (like parent vs child being in different groups), the more work it takes to see they're actually related. OTOH, if you over-group the spans, then the comparison becomes kind of pointless. We could have a checkbox or radio button to toggle between the variations? What do you think? @yurishkuro, do you want to weigh-in? |
@tiffon May be it would be good to have a way to select between variations, to allow us to try it out with different scenarios. |
@objectiser Thanks for the feedback. I wanted to add two more grouping approaches that recently came up:
The current comparison is very ancestor oriented, which can be problematic. For instance, if two traces are exactly the same with the exception of the root node, they will show up as two completely different trees with no overlap. Depicting a service-operation once is a very simple approach which would alleviate this (at the cost of quite a bit of detail). The second option is to do the same thing but consolidate on the service level instead of service-operation. So far, the list of comparison options might be:
|
So an interesting interview question - given two compressed trace trees, can we determine through some algorithm if they should be matched at roots or at a subtree of one of them? |
I want to note @yurishkuro's suggestion of showing the options as a series of checkboxes. Enabling a lower-checkbox would automatically enable any checkboxes above. I.E. you cannot have only the first and last checkboxes enabled. For instance: Two spans are in the same group iff:
|
Requirement - what kind of business use case are you trying to solve?
Compare should only show differences as red or green.
Problem - what in Jaeger blocks you from solving the requirement?
Firstly wanted to say that the new compare feature is great. However when trying it out on the Istio bookinfo example I noticed that it is showing a particular node (
istio-mixer
op:/istio.mixer.v1.Mixer/Check
) as being added and removed under the same node - the only difference is that the green version of the node has a child span.The same issue occurs in multiple places in this particular example - shown twice in this image.
Proposal - what do you suggest to solve the problem or improve the existing situation?
If there is no difference between these nodes, then the compare should only be showing the addition of the child span. If there is a difference between these nodes that results in the green/red distinction, then the difference also needs to be included in the graphical representation, otherwise it is not clear.
Any open questions to address
The text was updated successfully, but these errors were encountered: