search

tokio-rs / console-gsoc

Google Summer of Code tokio-console prototype
MIT License
12 stars 2 forks source link

Group events by parent span #31

Open hawkw opened 5 years ago

hawkw commented 5 years ago

This is a follow-up from #30.

It could potentially be very useful if events could be grouped by their parent spans, rather than by when they occurred temporally. That way, rather than rendering a linear series of events, we could have a mode where events are rendered as a tree under their parent spans.

This might look similarly to the slog-inspired example in tracing: Screen Shot 2019-07-24 at 1 32 10 PM However, in the example, the events and spans are still grouped temporally, indentation is used here just to indicate which events are children of a given span. This is because the example simply writes lines to standard out. The console, on the other hand, dynamically updates the whole view, so we have the ability to show a tree mode where all children of a span are printed under a single tree entry for that span.

I'm not sure if tui-rs's list widget can be used for a view like this or not (since it's not clear from the docs whether lists can be hierarchical), but there is also a feature request for a tree view widget: https://github.com/fdehau/tui-rs/issues/60

If we implement our own tree view widget, it could probably be contributed back to the tui crate eventually.

hawkw commented 5 years ago

Of course, this kind of implies the possibility of arbitrary grouping operators in the query language. That would be nice to have, but sounds like a bit of work. I think grouping by parent spans is a common enough use-case that we should support it as soon as it's practical, while arbitrary group-by operators seems a bit further out.

matprec commented 5 years ago

I'd prefer to implement it in terms of a group by operator, that seems straight forward to me!

Re: widgets, i'm mostly just ~ab~using the paragraph widget, because it gives me inline text styling options and i implement everything else on top of it. The API of their specialized widgets are lacking (good) customizability/styling options. Once gsoc is over and we have reached a more operable state, i plan to upstream my widgets and api pet peeves, but for now i'll go with my custom solutions :)

hawkw commented 5 years ago

I'd prefer to implement it in terms of a group by operator, that seems straight forward to me!

That's reasonable! I just think that this is an important enough use-case that it should be implemented even if arbitrary grouping operators are further out. I might even go so far as to suggest that grouping events by parent span should probably be the default view...

Once gsoc is over and we have reached a more operable state, i plan to upstream my widgets and api pet peeves, but for now i'll go with my custom solutions :)

👍