Add time frames handling to TotalCountMetric
What does this MR do and why?
Related to #411264 (closed)
We want to make it possible to create Redis metrics that are contained inside 7d/28d time frames.
To handle that, we will be saving the periodic redis data under weekly redis keys. This is based on a PoC: !120845 (diffs)
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
- Back on
master
branch, visit the analytics dashboard page:- Make sure that Service ping is enabled:
::ServicePing::ServicePingSettings.enabled?
should returntrue
in the console. If it doesn't - check how to enable Service ping here - Enter a project and go to
Analyze
->Analytics Dashboard
. This may require enabling a feature flag, more details here - Enter a dashboard from the list
- Make sure that Service ping is enabled:
- Make sure that you triggered some events, by running
redis_counter_key = Gitlab::Usage::Metrics::Instrumentations::TotalCountMetric.redis_key('user_visited_dashboard', Date.today); Gitlab::Redis::SharedState.with { |redis| redis.get(redis_counter_key) }
in the console: it should return a number bigger than 0. - Check out this MR's branch
- Refresh the dashboard analytics page. Verify that the old redis counter is still working, by making sure that
Gitlab::Redis::SharedState.with { |redis| redis.get(redis_counter_key) }
still increases after reloading the website. - Make it possible to time travel, by running
require 'active_support/testing/time_helpers'
and theninclude ActiveSupport::Testing::TimeHelpers
- To also verify monthly statistics, trigger additional events 2 and 5 weeks ago:
[-2.weeks, -5.weeks]. each { |period| travel(period) { Gitlab::InternalEvents.track_event('user_visited_dashboard', user: User.first) } }
. This should make it so that themonthly
redis count is set to1
more than theweekly
count (as only the event happening 2 weeks ago should make the cut for a monthly range). - Generate next week's service ping:
sp = travel(1.week) { Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values) }
- Check the values for periodic redis metrics:
sp['counts'].values_at('analytics_dashboard_visits_monthly', 'analytics_dashboard_visits_weekly')
. The values should correspond to monthly/weekly/total times the analytics dashboard website has been visited. Monthly count should be higher than the weekly count by1
[as it has been simulated in point6
].
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Michał Wielich