Add ability to display unadjusted trace in the UI

[black-adder]

We added the ability to view the raw unadjusted trace json in the UI. However, it would be nice if we could actually visualize the unadjusted trace for certain use cases:

1. debugging would be easier (if we are double emitting spans, a visual representation will make the issue clear as day)
2. FollowFrom spans are currently "normalized" to fit into the parent span (clockskew.go adjuster should skip FollowsFrom spans jaeger#448) which isn't ideal. While that ticket is in progress, seeing the raw trace would be useful for some users.

Parent issue: jaegertracing/jaeger#961

[MichaHoffmann]

If you would provide me with some pointers where to start; i would be willing to tackle this issue!

[yurishkuro]

@MichaHoffmann this requires some backend change per the parent issue jaegertracing/jaeger#961, but if you could propose changes for the UI to add visual cues of clock skew adjustment, it would be very helpful (even the design phase).

[MichaHoffmann]

@yurishkuro i was thinking of querying the query service with ?raw=true; shouldnt that return unadjusted traces, that we could just render normally? One could toggle this raw mode with a checkbox. What is missing in the Backend? I would be glad to help there too!

[yurishkuro]

?raw parameter disables all other adjustments, in some cases the result would break the UI. I don't know of a good reason to disable other adjustments besides clock skew, that's why I think we need and API extension for that on the backend.

On the UI, I suppose we could start with just a toggle, but I was thinking of some visual indicator on the spans themselves to make it obvious that some of them have been shifted on the timeline.

[MichaHoffmann]

In my usecase the adjustments make the traces unsuable, sadly. Its hard to imagine a visual indicator that would not clutter the UI ( in case of large traces even more so ). Its correcting the events that should logically and temporally be last almost to the front ( also shifting them vertically ). I feel that toggeling the query paramter ( that has to be introduced maybe ) has less points of failure then improved rendering.

Edit: What do you think of just passing the enabled renderers to the query backend via query paramters? One could then just select the adjusters that are wanted.

[yurishkuro]

Its hard to imagine a visual indicator that would not clutter the UI

The indicator can be relatively subtle, like a small red dot on the span bar. But like I said, we can do that later.

The current adjusters are here:

https://github.com/jaegertracing/jaeger/blob/ed6acfb6ed594598e2ac0500d796b9519c488a61/cmd/query/app/querysvc/adjusters.go#L23-L29

In order for the user to be able to select adjusters, we need to make UI aware of them. The actual list today is customizable by building a custom binary. I don't think it's prudent to make the end user fully aware of all the adjustments done by the UI. So far clock skew is the only one that makes sense to control.

[MichaHoffmann]

I would ( maybe in addition to the indicator ) appreciate the option to turn the clock-skew adjustment off. For testing purposes i did build a custom binary, is this the recommended approach?

I would love to start working on the queryservice, could you help me getting started? I imagine adding an 'adjusted' field to the response is necessary to render the red dot. Also propably an additional boolean query paramter 'skew' or something that filters the clock skew adjuster during the adjustment phase.

[bbigras]

Any progress on this?

[yurishkuro]

nobody claimed this, it's up for grabs

[prongs]

This would be a hugely useful feature addition. In my case, the actual span times are correct and the UI is applying adjustment randomly, which ends up incorrectly reordering the spans.