Prometheus: Show results of instant queries as text, not in table

[ivanahuckova]

What would you like to be added:
We are currently showing results of instant queries in the table. This way, we split labels into separate columns. Based on feedback from community and discussion with @gouthamve, this can is impractical. Reasons why it is impractical:

• If you have many labels on series, the table either gets super wide (because table rows can't wrap) or you have to hide some labels. It is hard to see everything.
• It is hard to copy-paste values and labels to use them in the your next query. You could use filter-for/filter-out functionality of table, but with that, you can do just 1 label at a time. If you know you want to filter for multiple labels, it would require you to use more resources to filter them one after the other (running multiple queries). Moreover, with having label in column, you are not even able to copy-paste label-value pair.
• We are using virtualized table which means that that if you have a lot of rows, you can't search for all labels. Searching for labels is very important and the fact that not all of them are searchable is big problem.
• Users would prefer "less-magic" and "more-control"

Why is this needed:
Improve experience for Prometheus users.

[davkal]

This keeps people using the vanilla UI for Prometheus.

[evandandrea]

One idea raised by @itsmylife is that we could have a toggle to flip between table and text view.

@obetomuniz is going to dig into the current state of how these results are presented and follow up with @ivanahuckova for further clarity.

[obetomuniz]

As for:

• If you have many labels on series, the table either gets super wide (because table rows can't wrap) or you have to hide some labels. It is hard to see everything.
• It is hard to copy-paste values and labels to use them in the your next query. You could use filter-for/filter-out functionality of table, but with that, you can do just 1 label at a time. If you know you want to filter for multiple labels, it would require you to use more resources to filter them one after the other (running multiple queries). Moreover, with having label in column, you are not even able to copy-paste label-value pair.

The current results should have a similar user experience as in the Prometheus Dashboard (screenshot). That experience allows users to select, copy and paste queries in a way they are already familiar with.

Ideal User Experience for this area:

Current User Experience for this area:

As for:

• We are using virtualized table which means that that if you have a lot of rows, you can't search for all labels. Searching for labels is very important and the fact that not all of them are searchable is big problem.
• Users would prefer "less-magic" and "more-control"

We should investigate this to understand how big the problem is to define a plan to solve it in a way that is familiar for users usage.

@grafana/observability-metrics is working to create an initial proposal for this.

[gtk-grafana]

I have created an initial implementation of the project that Beto outlined above:

Since this is a virtualized list component, we must hardcode the height, or calculate the height for each box on the fly (expensive), for this MVP I have opted to display a consistent height, but enable horizontal scroll so users with narrower screens can still interact with all of the content.
Scrolled content

I believe a better long term solution to the problem above is to let users tap on rows, which will open up vertically (accordion) and allow users to view the entire query, and filter by individual attributes (but this will need to be address in another issue).

Desktop view:

Misc observations so far:
The new view is much better at handling large amounts of data than the table view, even on a beefy PC the table view gets memory hungry and scrolling is jumpy and content takes a while to load.

Other design stuff I want to review with UX/design:

• I'm currently using pure red and green for text markup, what text color should we be using for each theme?
• Discuss compromises for smaller screens
• Copy icon size, placement, functionality, tooltip text?
• Value styling
• I inserted a new element in this view borrowed from the prometheus UI, keep or delete?

At this point I'm going to schedule another call with UX folks to get final direction on design and present the proposed MVP functionality, and then I'll work with logs team to figure out how to get this prometheus specific UI reviewed and merged.

[gtk-grafana]

After chatting with UX folks we made some minor tweaks to the styles, here it is after the updates:

UX was fine with the new UI element displaying the number of series returned by the query so I'll keep that in for now.

[gtk-grafana]

So while I've got a solution for this that works with a single prometheus query, multiple queries are complicating things since Grafana seems to combine all results into a single results section, but the native prometheus UI has a results section for each query. I tried adding a toggle to allow users to toggle between values for the various queries, but the combined query returns different results then individual queries run separately.

I think we'll have to follow the native prometheus example and create a result section for each query, but I want to review this plan with UX before starting.

Multiple queries native prometheus UI:

Work in progress UI confronted with multiple queries:

Tried to clean up the above, but abandoned this idea because of how bad of a job it does displaying the values:

[gtk-grafana]

After a discussion with the UX team, @diegoadams wanted some time to do some user research around multiple (prometheus) queries. Moving to a blocked state for now, but I am interested if there is an iterative solution we can release without fully solving the multiple query problem.

[gtk-grafana]

So after much thought and discussion on this, we decided to move forward after providing an additional expanded view that will only show values that are not undefined for each series, and the ability to toggle between this new "expanded" and "collapsed" views depending on the users use case, while still highlighting the ability to copy series as PromQL query strings.

While there are still issues "seeing everything" in the collapsed view (especially with many/long label names/values), the new expanded view should be able to display all of the information returned for a single metric within the users viewport (i.e. without scrolling), and the collapsed view provides an easier way to compare metrics (and their values). I don't think we can choose which UI is correct (in regard to collapsed vs expanded) programmatically, as it depends on the user and their data, so I believe letting the user decide between these is the correct decision.

Although note that the collapsed view also doesn't reserve space for values that are not applicable to the current series, so there are two variables at play between the two views, rendering each label/value pair on its own line, and including the value names inside the list item, as opposed to placed above like a table header.

https://user-images.githubusercontent.com/109082771/208957906-5cdb5082-7bac-47ee-9c67-44a79ec92fc0.png
https://user-images.githubusercontent.com/109082771/208957958-4695d88e-53ce-461f-8443-85c92b16753a.png

^^ The Github WYSIWYG isn't letting me upload images, just going to link them for now and I'll try to update soon.

[gtk-grafana]

Yahoo! We've merged in the MVP implementation to main, and these changes will be released in 9.4.0. This was a much bigger lift than anticipated, but I'm really proud of what we've accomplished so far. Thank you to everyone who helped on this @obetomuniz @ivanahuckova @diegoadams @davkal @Elfo404 @gelicia @bohandley @itsmylife @evandandrea and more.

We'll be adding some tracking events in #60990 (WIP) to help gather some base usage statistics.