Skip to content

Add time frames handling to TotalCountMetric

Michał Wielich requested to merge michold-redis-timed-tot into master

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

  1. Back on master branch, visit the analytics dashboard page:
    • Make sure that Service ping is enabled: ::ServicePing::ServicePingSettings.enabled? should return true 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
  2. 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.
  3. Check out this MR's branch
  4. 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.
  5. Make it possible to time travel, by running require 'active_support/testing/time_helpers' and then include ActiveSupport::Testing::TimeHelpers
  6. 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 the monthly redis count is set to 1 more than the weekly count (as only the event happening 2 weeks ago should make the cut for a monthly range).
  7. Generate next week's service ping: sp = travel(1.week) { Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values) }
  8. 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 by 1 [as it has been simulated in point 6].

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Michał Wielich

Merge request reports

Loading