Introduce EventSelectionRule class
What does this MR do and why?
Since the relation between metrics and events are becoming more and more complex because of filters and unique properties, I think it is time to introduce a new class to hold the data and logic that currently live in different places of the codebase.
This MR is a big refactoring, and doesn't add or remove any functionality.
The plan to implement #435338 is:
- Implement filtering for total count metrics
- Refactor key-generation logic
- Implement filtering for unique count metrics
This MR addresses item 2).
The main responsibilities for the new class is to:
- hold information about the relationship between an event and a metric
- be the sole responsible for generating Redis-keys in all Internal Event metrics
This MR is also laying some of the groundwork for adding filters to unique counters, so please keep that in mind when reading through the changes. (POC for adding filters to unique counter metrics)
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
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
Try to trigger a few events in the rails console and see how they update in the monitor:
Gitlab::InternalEvents.track_event('user_clicks_comment_filter_dropdown', user: User.first). (user_clicks_comment_filter_dropdown is a good candidate since it is used in both total count and unique count metrics)
Related to #435338