Collect telemetry and metrics directly in GitLab
Problem to solve
When releasing a new application or a new feature to an exisiting application it can be valuable to collect metrics and usage statistics (typically referred to collectively as 'telemetry' data) about the usage of that feature.
- Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
Use cases include things like:
- GitLab is adding a new feature called
suggestionsthat allows users to suggest changes to a line of code in a Merge Request. How many people use this feature in the first 30 days after release?
- How much is the usage of a stage growing over time? (e.g. SMAU)
- Collecting metrics on a feature to make UX decisions
- A/B testing the method of displaying a feature to a user
- Deciding to deprecate support for a set of features
This directly contributes to our ~"Product Vision 2019" and our plan to rebuild in GitLab those items required for a complete DevOps lifecycle management tool in a single application.
There are a number of ways we could implement this, I don't think I have an opinion currently...there was a detailed (internal) discussion here: https://gitlab.slack.com/archives/C0NFPSFA8/p1551463148058200.
- Integrate into APM / Monitor some concept of generic metrics either time based or otherwise.
- Extend the Release feature around Feature Flags to send data back about the usage of a given flag
- Have Fulfillment build first-class telemetry directly into GitLab as part of their plans around usage ping
- Some combination of all of the above or using a generic library for telemetry such as Microsoft Application Inights
Permissions and Security
I think it makes sense that Maintainers and above would have access to this data, thought I could see an argument for large spred of data.