[Traces] Spans hierarchical timeline

[sthobis]

Description

This PR replaces the previous Gantt chart component in Trace with a more comprehensive hierarchical timeline. While the Gantt chart showed span lifetimes well, it didn’t effectively communicate parent-child relationships between spans. The tree view solved this to some extent, but switching between tree and timeline views was disruptive, as both reset their state.

We also introduce a new side panel with a service filter to help navigate relevant spans. It's built using raw canvas (for the minimap) and HTML for better customization, as Plotly's bar chart isn’t well-suited for hierarchical layouts.

Basic Cypress tests are included for both the timeline and service filter components.

Before	After

Screen.Recording.2025-07-22.at.19.07.01.720p.mov

Issues Resolved

Check List

• New functionality includes testing.
  • All tests pass, including unit test, integration test and doctest
• New functionality has been documented.
  • New functionality has javadoc added
  • New functionality has user manual doc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[oberkem]

not sure I fully grok the meaning of these changes in this PR.

1. what do the numbers here on each operation denote? is it number of spans?

2. similarly what does the numbers next to each service denote? number of spans?

3. I suspect service name ordering is done by alphabetical order but service name order should be the rpc order. If I'm in trace view as an operator, my context is to understand the dependencies & the call order, and where the biggest latency is coming from

4. I found the boxes around the spans visually confusing

5. I found ordering change of spans to be confusing as well. It looks like we had a ordering bug in "before" as well - http post from FE should be on top. In the after screenshot HMSET should be the 3rd item from top.

6. Filtering spans by service in theory seems like a good idea but in this example there is a big gap between HMSET and GetCart in Cart Service. As an operator I would be thinking why there is a gap between operations

[sthobis]

Hi, thanks for the reply!

1. The number shown represents the count of child nodes under a span.
2. Yes, it's the number of spans that belong to the corresponding service.
3. Fair point, ideally these panels should be more cohesive so we wouldn’t need both. That said, I can update the ordering to follow RPC order, which as you mentioned, makes more sense.

4. Happy to work on this. Do you have any suggestions on how we can make it less confusing

5. You're right the "before" chart had a bug in ordering items with the same rounded timestamp. In the "after" screenshot, it might seem like the item should appear in the third row, but the underlying data suggests otherwise when considering the hierarchy and dependencies (maybe just weirdness in the sample data). Here's another example where combining the "tree view" and "timeline" provides a clearer picture.

Before	After

[ps48]

Thanks for the PR @sthobis
I am not a fan of adding more dependencies on the projects. The needs more maintenance, more CVE fixes and tree/dependency checks. Can we use something that already exists in OSD core. I see we have d3 and vega-lite there. Would be great if we can use them.

I know many projects in the OSD core, including the new discover pieces are using vega-lite as a standard.

[TackAdam]

Hi @sthobis ,

OpenSearch-Dashboards is looking to move away from plotly, we have a feature coming out for OpenSearch Dashboards where I have started the refactor to make a gantt chart using vega-lite instead.
opensearch-project/OpenSearch-Dashboards#10253. Your changes presented here are great and what we are moving towards that with the the mini-map and collapse fields for the parent child structure.

I believe vega would allow much more functionality for making the collapse structure in a more visually clear way avoiding the confusion of the box structure called out above.

These changes were planned to come to Traces here in the September time range, but I would be happy to work with you on switching this to vega if you wanted to start incorporating those new great features into the vega version.

[synhershko]

@TackAdam a lot of good work and effort has been put into this -- wouldn't it be possible to merge it in (after any concrete feedback applied) and then move to another graphing lib?

[TackAdam]

@synhershko Thanks again for all the effort that’s gone into this. We’ve now posted the RFC outlining our upcoming changes to the Traces experience in OpenSearch: opensearch-project/OpenSearch-Dashboards#10382. I’d really value your feedback there. From that discussion, we can decide together whether it makes sense to move forward with this in the interim (with some necessary UI adjustments), or redirect the work toward the new component proposed in the RFC.

[opensearch-trigger-bot]

This PR is stalled because it has been open for 30 days with no activity.

[synhershko]

Attending OSCon so haven't responded to the RFC yet but will do so soon. In the meantime, @kgcreative mentioned he has some feedback ?

[kgcreative]

This is great! I think the main feedback i'd have is to remove the borders across all the containers. It makes it a bit difficult to parse visually and adds a lot of noise. I would have expected something with a similar interaction as a tree view (https://oui.opensearch.org/1.21/#/navigation/tree-view)

Ideally we could enhance tree view to make it easier to grok the nesting like so:

[opensearch-trigger-bot]

This PR is stalled because it has been open for 30 days with no activity.