Add property_name handling for InternalEvents
What does this MR do and why?
Related to #415139 (closed)
Make it so that all the Internal Events use the new property_name
argument for RedisHLL counter.
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
- All the described steps should be performed once for an internal event with just one RedisHLL unique_by property [for example:
g_project_management_issue_weight_changed
] and once for the event that has been expanded with this MR and has currently two unique_by properties [user_visited_dashboard
] - Enable the feature flag:
Feature.enable(:redis_hll_property_name_tracking)
- Check the count for the chosen event for each of the property_name [for example:
Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'user_visited_dashboard', start_date: Date.yesterday, end_date: Date.tomorrow + 7.days, property_name: :user)
andGitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'user_visited_dashboard', start_date: Date.yesterday, end_date: Date.tomorrow + 7.days, property_name: :project)
] - Trigger the chosen event. This can be done either by performing its assigned action in gdk [
g_project_management_issue_weight_changed
: change an issue's weight,user_visited_dashboard
: enter an analytics dashboard for a project] or manually, from the rails console [for example:Gitlab::InternalEvents.track_event('user_visited_dashboard', user: User.first, project: Project.first)
] - Trigger the event again, with different
unique_by
properties [for example:Gitlab::InternalEvents.track_event('user_visited_dashboard', user: User.second, project: Project.first)
would have a newuser
value but oldproject
value] - Check the count for the chosen event again [sample commands are listed in point
3
]. The values should be increased by 1 for each time thattrack_event
has been called with a unique property.
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