Track how often generic-metric type reports are created in merge requests with usage ping
Problem to solve
With https://gitlab.com/gitlab-org/gitlab-ee/issues/9788, we introduced a new "generic metrics" feature as a new report type in Merge Requests.
So that we can iterate on that new feature we need to be able to track how often it is being used. This should add a count for the number of times this particular type of report artifact is uploaded from a job.
Intended users
This is for internal GitLab use.
Further details
We want to know how often the generic metric is being used so we can identify and dig into common use cases to potentially build that into the product so users get it by convention not configuration.
Proposal
Using usage ping tracking, create a new usage ping data point for unique users who have generated a pipeline with a metrics report per week.
In the follow scenarios send the user_id to the redis HLL tracking key for unique users who have generated a pipeline with a metrics report this week in usage ping:
- A user has created a merge request that has triggered a pipeline that uploads a metrics report
- A user has triggered a pipeline manually that uploads a metrics report
This data should be tracked weekly. i.e. if user_id: 123 performs this action in both week 25 and week 26 they should be counted in both weeks.
Permissions and Security
- This does not need any special permissions for viewing in Periscope
Documentation
N/A as internal
Availability & Testing
- Validate successful and error scenarios for upload such that both types show up in periscope
- Let's make sure we can't break the data pipeline with too long report types.
What does success look like, and how can we measure that?
- Success will be that there is data as defined in the proposal flowing into periscope that can be queried after launch.
What is the type of buyer?
Links / references
Understanding how many customers are making use of this feature will inform if / when we move forward with enhancements like #9789