Show only events which match filter in Issues screen. (also event & user count)

[Malachiasz]

Summary

I would like to be able to see only events (user, event count and the graph) send by specific release in the Issues screen.

Motivation

When releasing new version of mobile app I want to fast see the number of events. Currently The filter is applied on Issues only, but all issues which match filter include all the events sent with not matching filters as well.

For example I am filtering issues for the release version 10.2.0: "release:10.2.0", the result will be all the issues which occurred at least once with version 10.2.0, but the numbers for users and events counts are often in tens of thousands. It's a usual case, because they are a warning level issues, which are not supposed to be resolved in previous releases.

Additional Context

It's not convenient to watch the release screen and always wonder weather warning level issues are increasing or decreasing.

[aranda-adapptor]

This is my # 1 gripe with sentry. Other tools such as Crashlytics allow you to apply fliters to issues (in particular release version) and see the volume of issues occurring for that filter condition. With Sentry this is nearly impossible, the only way to get a feel for it seems to be to open the issue and click through the individual instances of it whilst watching the release version.

[RevZero]

This would indeed be very helpful. Is should at least be possible to show only events from a specific release. This filtering should be possible in the Issue overview and from the Issue details.

As pointed out before, you do not get a useful representation from the Issue overview on how much the latest release is affected by some issues that still appear a lot in older versions. And it is very cumbersome to click through all the events, when you want to look at events from a specific version.

[martinspaeth]

We moved from crashlytics to sentry. And after our first impression the step represents a strong improvement for us. The integration into gitlab helps us a lot. Thanks for the awesome work!

The behaviour of the event and user column was a bit counter intuitive for me. It took me a while to understand that the filters applied to the list of issues does not apply to the events and user column. As stated before the enriching the information could be very helpful.

An ideal UI for the issue overview for me would look as follows:

In stead of showing always the total amount of events and users it would be very helpful to show two different numbers in both columns.

(A) would show the number of all events / users for the selected env AND timeframe
(B) would show the number of events / users found affected in respect of the applied search

By having those numbers side by side one would be able to trill down the impact of all matching issues for the applied filter like release/operation system when looking at (B) while the second number (A) still gives a good impression of the impact of the problem in the chosen environment and time frame.

[martinspaeth]

Related issue: #20006

[Oshin159]

we are facing the same issue, the event count remains an aggregate count. It becomes hard to figure out what are the trends for specific filters. Even if I go the release page this is the case.

[martinspaeth]

Bis there any way to push this topic? I was diving into the sources and in the way u structured the computation and database lookups it didn‘t look line a very huge thing so, happy to assist

[BYK]

Ping @adhiraj @taylangocmen

[martinspaeth]

Thanks @BYK for delegation and the update.

[adhiraj]

We're working on a solution similar to what @martinspaeth suggested.

Related question for those following: we're also looking to connect the time selector on the top right with the per-issue bar graph. Currently the bar graph shows 24h of data regardless of what time period is selected (with an option to see 14h). Would you rather have the graph reflect the same range as the time selector by default? Would you wanna retain a 24h option as well?

[martinspaeth]

Nice to hear that we can expect this in upcoming releases, this will help us a lot. Regarding the graphs:
I would stick with the both options u currently provide (24h and 14d). I feel like this visualization should stay comparable on the x axis and there for independent from the selected time frame of the filter. But I would recommend to reflect the other filters on the y axis. It would be neat if the bar chart shows the original data (without a filter applied) in - light gray - in the background. This would also make the y axis comparable:

[aranda-adapptor]

I like the idea @martinspaeth mentioned of showing both filtered and unfiltered data in the per-issue bar charts, but I also think there is value in matching the X axis with the overall date range. Perhaps another option GRAPH: 24h, 14d, *All* would work.

[martinspaeth]

A problem u face with non fixed time ranges like the selected time or even the „all“ option would be the bucketing of the events.

If one event In the List occurred 3 years ago for the first time and another just two weeks ago u have to fix the amount of bars and what they represent to give the y axis any reasonable meaning when drawn in the list (they should be visually comparable I think).

While u could use 36 Bars And would bucket by month in this case - based on the biggest time frame - it would change depending on the filter. So this would not help to get an overview within the list but would create more noise.

What information would u like to extract from this additional graph and how would u solve this @aranda-adapptor ?

May this „all option“ should be put on top of the Events details View instead given their is more space to draw a graph the important information like what time window etc could be put next to the axis than (fabric choose to do that and it was quite helpful) But that would be a different feature than.

[aranda-adapptor]

Rather than All, I should have called the option Selected as I meant it to match the current selected date range.

The reason I think this is useful is that sometimes you want to see issue frequency earlier than 14 (or even 30) days. If Sentry opted to have another screen (or use the Event Details page as you suggest) that graphs specific issue frequency over an arbitrary date range, then I agree, this feature would not be that useful in the issue list page.

Handling the bucket sizes is definitely tricky, although that would be up to the smart Sentry people to solve. One idea would be to have buckets sizes be [year, month, day, hour] and depending on the date range, choose the "best" option. You could (for example) choose the most granular bucket size such that there are < 100 buckets.

[EDIT] Just want to clarify, I think fixing the filtering of issue counts and the 24h/14d graph results is definitely the biggest priority. Any further graphing improvements are icing on the cake!.

[martinspaeth]

@adhiraj can we provide any further input / help on this topic? This ticket would make release health comparison so much easier...