Enhancements to TraceGraph

[copa2]

Requirement - what kind of business use case are you trying to solve?

This is a follow-up of #276 and serves as meta-ticket. It should try to get feedback from users what should be changed and enhanced in the view.

Please add a comment with your ideas how the view should be improved. You can also upvote/downvote ideas directly on the comments.

This is a summary of the ideas gathered in this issue:

Nodes

• Use better color scheme for node backgrounds in time and selftime. (Enhancements to TraceGraph #293 (comment))
• Don't color leafs in self time as they are always 100 %. (Enhancements to TraceGraph #293 (comment))
• Render nodes differently. (Enhancements to TraceGraph #293 (comment))
• Support search in nodes (already in progress Add ability to search for nodes in TraceDiffGraph and TraceGraph #307)

Aggregations

• Show other data properties in nodes. (Enhancements to TraceGraph #293 (comment))

Node Details

• Provide a Nodedetail view with additional information to the selected node. (Enhancements to TraceGraph #293 (comment))

Varia

• Use redux store for mode changes (TraceGraph -> DirectedGraph -> OpNode)

[tiffon]

For the coloring of nodes, I recommend:

• Using a square root scale, e.g. LOC
• Using the color range #dddddd to #a8071a, which is a light grey to a deep red
• Using the actual max of the values for the color scale instead of 20% – the square-root scale for interpolation goes a long way to preventing relevant values from being washed out
• Interpolating the colors based on either the CIELAB or CIECAM02-UCS Jab colorspaces. See this comparison with Lab and RGB. d3.interpolateArray might be helpful.
• Coloring the text based on the color of the node, see below for an implementation

jaeger-ui/packages/jaeger-ui/src/components/TraceDiff/TraceDiffGraph/getColorInterpolator.js

Lines 43 to 67 in 1d28725

	const LUMINANCE_THRESHOLD = Math.sqrt(1.05 * 0.05) - 0.05;
	// the method for determining if ligth or dark text should be used
	// https://stackoverflow.com/a/3943023/1888292
	function adjComponent(value: number) {
	const n = value / 255;
	if (n <= 0.03928) {
	return n / 12.92;
	}
	return ((n + 0.055) / 1.055) ** 2.4;
	}
	function getTextColor(colorString) {
	const cached = textColorCache.get(colorString);
	if (cached != null) {
	return cached;
	}
	const { r, g, b } = rgb(colorString);
	const luminance = adjComponent(r) * 0.2126 + adjComponent(g) * 0.7152 + adjComponent(b) * 0.0722;
	// const values = [r, g, b];
	const v = luminance > LUMINANCE_THRESHOLD ? DARK : LIGHT;
	console.log(colorString, 'l', luminance, v);
	textColorCache.set(colorString, v);
	return v;
	}

[tiffon]

Node metrics / aggregations

Currently, the metrics shown on the nodes are:

1. TL (Top left) - Count
   • Number of spans contained in the node
2. BL - Duration
   • Cumulative duration of the spans contained in the node
3. TR - % of trace duration
   • Duration (Adding Travis Integration #2) / trace duration
4. BR - Self-time
   • I believe this is cumulative (lmk if I'm wrong)

This very much gives a sense of scale for the node with regard to how it contributed to the trace, as a whole. And, it is possible to compare groups with one another, but mainly as "How much did this group contribute to the trace vs that group", so, still as the node relates to the full trace.

Since everything is the sum, the metrics are very sensitive to the count. And, that makes it tough to compare groups of different sizes because a group with more spans will have higher totals even if the spans were executed in parallel and therefore are less relevant than a smaller group of spans there were not concurrent.

I'm curious about switching to the following metrics:

1. TL - Count
   • Number of spans contained in the node
   • Unchanged
2. BL - % of trace duration
   • Sum of durations as a percent of the trace duration
   • Moved from TR
3. TR - Average span duration
   • Sum of durations / count
4. BR - Average % self-time
   • Average % self-time (distinct from sum of self-time / sum of durations)

The left-of-center metrics are cumulative and speak to the contribution to the trace as a whole. The right metrics are averages.

A screenshot:

[copa2]

#293 (comment) Coloring of nodes

Thanks pointing to the different coloring schemes.
Will try to change this with given colors and using square-root scale.
Regarding interpolation for LAB. d3 already has d3.interpolateLab.
You also provided some code. Probably we should add it to https://github.com/jaegertracing/jaeger-ui/tree/master/packages/jaeger-ui/src/utils so that it is usable from different components.

[copa2]

Leafs in ST (selftime) are always full red as self time is always 100 %. So this puts attention to these nodes even if they are not important.
Don't color the leafs or use another concept for marking nodes with a high self time.
Probably better color self time in comparision to total trace time instead of single trace time.
Sidenote: Self time should help to identify nodes which use a lot of time. These are mostly due to locks, big calculations or other not tracked time.

[copa2]

A node currently contains a lot of details, probably too much details (information overload).
Consider to keep only provide the most relevant data.
To still provide the information provide a nodedetail view. This view will show more info for the selected node.

This contains info about:

• count
• errors
• average time
• total time ( % of total trace time)
• self time (% of node time)
• average self time

When there exist multiple calls (count) a graph will be shown. It provides time distribution of the different calls (total time (green) / self time (blue)). This should help to identify relevant patterns of these calls.

[copa2]

Render nodes differently

• Uses same node as in compare view

• Depending on content the size(x direction) is different

• Size (x direction) is always the same so graph is more calm

• Size is bigger (y direction) so whole graph gets bigger

• Uses left border for color like on trace search to identify the services

• Colors are only on the side, so when small not really visible

[obeyda]

Having the ability to focus the node in the trace timeline would be nice,
ie: focus a node -> switch to trace timeline -> the same node should be focused in the timeline view

[maxgaponov]

#1918 : Duration of overlapping operations is calculating incorrectly in TraceGraph view. The total duration for overlapping spans should be the duration of their union, but not the sum.