Add `agent_users_using_ci_tunnel_monthly` equivalent metric for GitLab.com at the namespace/project/user level
Problem to solve
We have instance+tier+MAU detailed data for Self-Managed agent usage with agent_users_using_ci_tunnel_monthly
. At the same time GitLab.com is a single Gitlab instance, thus we don't have the breakdown of data on gitlab.com.
To improve our reporting and planning, we would need namespace/project/user level data on gitlab.com equivalent or richer to agent_users_using_ci_tunnel_monthly
.
Proposal
Use the Internal analytics framework to implement gitlab.com only metrics for (in the order of importance):
- namespace-based MAU metric on overall KAS usage (equivalent to
agent_users_using_ci_tunnel_monthly
) OR project-based MAU metric on overall KAS usage (more detailed than the above as we can see usage at the project level; namespace-level data can be retrieved by aggregating to the namespace) where the project is the agent configuration project - project-based MAU metric on CI usage (a project-based equivalent to
k8s_api_proxy_requests_unique_users_via_ci_access_monthly
) where the project is the agent configuration project - project-based MAU metric on UI usage (a project-based equivalent to
k8s_api_proxy_requests_unique_users_via_user_access_monthly
) where the project is the agent configuration project - project-based MAU metric on PAT usage (a project-based equivalent to
k8s_api_proxy_requests_unique_users_via_pat_access
) where the project is the agent configuration project
If we should pick from the above for performance reasons project-based MAU metric on overall KAS usage is the most important.
Implementation
kas
kas can collect user ids grouped by agent configuration project in addition to all the same existing aggregated counters: k8s_api_proxy_requests_unique_users_via_ci_access
, k8s_api_proxy_requests_unique_users_via_user_access
, k8s_api_proxy_requests_unique_users_via_pat_access
. It can then send this information to rails as part of existing API calls in the usage_metrics
module.
We currently send the following data:
type UsagePingData struct {
Counters map[string]int64 `json:"counters,omitempty"`
UniqueCounters map[string][]int64 `json:"unique_counters,omitempty"`
}
We can do something like this:
type UsagePingData struct {
Counters map[string]int64 `json:"counters,omitempty"`
UniqueCounters map[string][]int64 `json:"unique_counters,omitempty"`
IntGroupedUniqueCounters map[string]map[int64][]int64 `json:"int_grouped_unique_counters,omitempty"`
}
We might want to group by strings in the future, so this one is named int_grouped_unique_counters
.
We then add k8s_api_proxy_requests_unique_users_via_ci_access_by_agent_project
, k8s_api_proxy_requests_unique_users_via_user_access_by_agent_project
, k8s_api_proxy_requests_unique_users_via_pat_access_by_agent_project
grouped unique counters and fill them with data.
Rails
Add the new counters above to the expected params and known events.