Adding different trace representations

[divdavem]

Hello,

I am opening this issue to discuss a new feature that we would like to add: the ability to switch between different representations of a same trace in the UI.

As traces can become very big and detailed (and difficult to read), and people looking at them may have different purposes, it makes sense to have different representations of the same trace to help investigating issues.

The idea would be to be able to define in the configuration a list of trace representations. Each representation would have a display name and a JS function that takes the raw trace as a parameter and returns a simplified trace. (This assumes #123 would be implemented, which would allow to define JS functions as part of the configuration.) The function could have any custom logic, such as, for example, merging similar spans together in one, or not including spans of less importance. The UI should then allow to choose which representation to display from the configured list of representations.

The simplest would probably be to choose between different representations at the level of the full trace, but maybe it would be good too to be able to apply different representations at any level in the CHILD_OF hierarchy?

If we open such a pull request, would you be interested in integrating it?

Please tell us what you think.

Thank you in advance for your answer!

[yurishkuro]

@tiffon is your plan for componetizing the UI documented in any issue?

[tiffon]

@divdavem Thanks for opening this ticket!

That's a really interesting take on handling the TMI problem. 👍

To confirm, the function(s) defined in the UI config would return traces with the same schema as the current traces, so the rest of the UI would essentially be unchanged?

The simplest would probably be to choose between different representations at the level of the full trace,

Agreed.

but maybe it would be good too to be able to apply different representations at any level in the CHILD_OF hierarchy?

Sounds great. Do you have something in mind for this?

If we open such a pull request, would you be interested in integrating it?

Contributions are definitely welcomed. 🎉

UI features are kind of consensus driven, so I'm curious to hear what others think of this feature. @yurishkuro, @black-adder, @whistlinwilly, @vprithvi. Care to weigh-in?

Also, I recommend writing up a doc outlining the UX and API to gather feedback prior to implementing, e.g. Trace Diff UI Comps. (Let me know if you have any feedback on the trace diff comps :)

Thanks again for opening this, and apologies for the delay in getting back to you!

[yurishkuro]

I'm not opposed to this feature since it sounds like a custom transformation of the trace that is fairly easy to support (once we support json config). If am not sure how useful if would be in practice though, it seems custom visualizations of the trace would cover this use case as well but are much more powerful.

We'd also better finalize the UI model, ideally by upgrading the UI to the new protobuf-based schema.

[tiffon]

@yurishkuro, @divdavem suggestion seems like a means to enhance the current trace-detail visualization. A couple of benefits are that it adds more value to the current trace-detail visualization and users are already accustomed to the UI / UX of the timeline view.

I agree custom visualizations are more powerful, but also more complex to design, implement and maintain and come with the typical variety of UX perils.

[divdavem]

@yurishkuro @tiffon Thank you for your answers!

To confirm, the function(s) defined in the UI config would return traces with the same schema as the current traces, so the rest of the UI would essentially be unchanged?

Exactly. The only change in the UI would probably be a new <select> element to choose which representation to display.

but maybe it would be good too to be able to apply different representations at any level in the CHILD_OF hierarchy?

Sounds great. Do you have something in mind for this?

I initially had the idea of having the <select> to choose the representation potentially at each span level (if there is more than one relevant representation at that level), and having a test function in each representation to know whether applying the representation would be relevant at that span level.
We are not sure yet if this is needed in practice, and it seems to make things a lot more complex, so we can probably ignore this idea for a first version of the feature, and only have one <select> at the level of a full trace.

Contributions are definitely welcomed. 🎉

Thank you!

Also, I recommend writing up a doc outlining the UX and API to gather feedback prior to implementing, e.g. Trace Diff UI Comps. (Let me know if you have any feedback on the trace diff comps :)

Ok, we will write such a document.

Thanks again for opening this, and apologies for the delay in getting back to you!

Thank you for taking the time to answer us. No problem for the delay.

We may also take some time before providing the doc with the UX and API, and later the implementation.
I have different things to do and I will also have some holidays soon, so do not worry if I don't answer quickly either.

[divdavem]

For information, for internal reasons in my company, we have to put on hold this feature.
We will unfortunately not have time allocated to implement it, unless there is another change in our plans.