feat(metrics): Use 10s granularity in front end [INGEST-249]

[jjbayer]

Release health stats stored as metrics can be queried with a resolution of up to 10 seconds. With this PR

• the frontend requests data from the /sessions endpoint with an interval of "10s" if the total requested period is < 10 minutes.
• Depending on which release health implementation is active, the backend then interprets "10s" as either 10 seconds (for metrics implementation) or as one minute (sessions implementation).
• The frontend then displays the 10s-resolution data and adds seconds to the time format of the x-Axis label (done in ref(charts): Add seconds to x-Axis when interval equals 10s [INGEST-360] #29350).

This can be viewed on the release details page:

[github-actions]

size-limit report

Path	Base Size (011c34f)	Current Size	Change
src/sentry/static/sentry/dist/entrypoints/app.js	52.74 KB	52.74 KB	+0.01% 🔺
src/sentry/static/sentry/dist/entrypoints/sentry.css	70.89 KB	70.89 KB	0%

[jjbayer]

The frontend changes were already approved in #29350.

[jjbayer]

@Swatinem I'm not sure which of the rounding rules in this function should also apply to metrics-based queries, especially the one about real-time queries:

sentry/src/sentry/snuba/sessions_v2.py

Lines 388 to 392 in d6c59c3

	# snuba <-> sentry has a 5 minute cache for *exact* queries, which these
	# are because of the way we do our rounding. For that reason we round the end
	# of "realtime" queries to one minute into the future to get a one-minute cache instead.
	if end > now:
	end = to_datetime(ONE_MINUTE * (math.floor(to_timestamp(now) / ONE_MINUTE) + 1))

If this is specific to the "sessions" dataset in snuba, it might be better if I created a separate implementation of this function for metrics-based queries.

[Swatinem]

The reason for this was that raw_query is being cached, keyed on the parameters you pass it (one of those parameters is the start/end times). That’s why this statement is there, to force a change in cache key and thus fetch a fresh dataset.

TBH, I have no idea if that is relevant for metrics-based sessions, probably not? I think you know better than me ;-)

[untitaker]

after asking around in slack, there's two caches: one in sentry, one in snuba

snuba cache is i suppose what arpad is talking about.. tbh I am not sure if it ever caches more than 1 minute. sentry cache is disabled by default

I think the code is fine though... I don't get the disjunction between rounding_interval and interval, but rounding by 1h is too much. In any case the end result should probably be that we round the timestamps down to next 10s bucket

[jjbayer]

Thank you both, I will create an additional PR to split the logic for sessions- and metrics-based queries into two separate functions.

[Swatinem]

The reason for this was that raw_query is being cached, keyed on the parameters you pass it (one of those parameters is the start/end times). That’s why this statement is there, to force a change in cache key and thus fetch a fresh dataset.

TBH, I have no idea if that is relevant for metrics-based sessions, probably not? I think you know better than me ;-)

[untitaker]

after asking around in slack, there's two caches: one in sentry, one in snuba

snuba cache is i suppose what arpad is talking about.. tbh I am not sure if it ever caches more than 1 minute. sentry cache is disabled by default

I think the code is fine though... I don't get the disjunction between rounding_interval and interval, but rounding by 1h is too much. In any case the end result should probably be that we round the timestamps down to next 10s bucket