Allow to filter by additional properties in Service Ping Metric
Problem
We see a proliferation of what we call "micro-frameworks" for analytics instrumentation, like the one referenced in #424893 (closed) or the ones referenced in gitlab-org/analytics-section/analytics-instrumentation/internal#687 (comment 1636912514).
A common pattern is that they apply some kind of string concatenation to create variants of what is essentially the same event happening, e.g. i_package_[x]_push_package where x can be any of debian, go, generic etc..
The developers behind these normally want to enforce consistency within their events which is a good thing, however, this leads to some downsides:
- a proliferation of very similar events which all belong to the same group, making the overall system harder to maintain since any change needs to be propagated to all "individual" events
- boilerplate code to handle creating the different versions of the event and ensure consistency
- any addition of another
xrequires additional work to make sure the micro-framework accommodates the new value
In many cases, the variable part of the string, the x, could be formulated as an additional property of the event. When using a label or similar additional property, i_package_[x]_push_package could become push_package, {label: '[x]'}.
However, stakeholders are still interested in "How many push_package events with label='debian' happened in the last week?" but we do not support the creation of such a metric yet, so the above solution to use additional properties only works for Gitlab.com as of this moment.
Desired Outcome
Allow the creation of metrics (unique/total counts) based on a specific additional property value in addition to an event.
Examples:
- A metric that counts the total amount of
push_package_to_repositoryevents with thelabelofmavenwithin a weekly time frame - A metric that counts unique users that performed the
push_package_to_repositoryevent with thelabelofnugetwithin a weekly time frame
Potential Solution
TBD
How to Verify
TBD