Instrument agent for Kubernetes ci_access impersonation
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Objective
Instrument the GitLab agent for Kubernetes ci_access.[].access_as values.
What share of CI access users use the various access_as settings? Are there any differences by licensing tier?
We already have redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_users_via_ci_access_monthly and variants to track monthly unique users of the CI access functionality. We should refine this metric further to allow for insights about the access_as usage
Events and Metrics
Definition of events and metrics | Sample metrics | Sample events
Details of events to be tracked:
| Event Description | Event Name | Additional Properties | Feature |
|---|---|---|---|
| Unique users triggering a job that uses the CI access functionality of the agent | k8s_api_proxy_requests_unique_users_via_ci_access (already exists) | access_as value, project_id where used (not where configured) |
Details of metrics to be tracked:
| Metric Description | Event / DB column to base the Metric on | Total or Unique Count of a Property | Time Frame | Feature |
|---|---|---|---|---|
Monthly active users of the CI access functionality by access_as setting |
k8s_api_proxy_requests_unique_users_via_ci_access | Total of monthly active users | 28d | |
| Monthly projects using the CI access functionality by access_as settings | k8s_api_proxy_requests_unique_users_via_ci_access | Total of monthly project count | 28d | |
Monthly agent count of agents using the CI access functionality by access_as setting |
Total of monthly agent count | 28d |
Expand to view examples and guidelines for filling the table
Events:
- Description: Include what the event is supposed to track, where and when.
-
Name: Primary identifier of the event, format: <action>_<target_of_action>_<where/when>
- Example event name: click_save_button_in_issue_description_within_15s_of_page_load (action = click ; target = save button; where = in issue description ; when = within 15s
- **Additional properties: Besides user/project/namespace, what other details should be tracked, if any? ex) status, type, object id, etc.
- Feature: What feature is being instrumented? Please use the feature title that is used in features.yml if thats already available.
Metrics:
- Description: What quantitative measurements derived from either event data or database columns would you like to track? eg: Weekly count of unique users who update an issue
- Event/DB column: What event or database column should the metric count or be based on.
-
Total or unique count: Should the metric count all occurrences or only unique counts, e.g. of
user_idto get a count of unique users triggering an event. - Time Frame: What time frames should be tracked. Default and recommended is 7d and 28d.
Next steps
-
Assign an engineering counterpart from your group to add instrumentation to the code -
Explore instrumented data with the help of our data discovery guide. You can also reach out to product data insights team for help with generating Tableau reports/dashboards. -
Your feedback is valuable to us. Please leave us feedback in the comment section of this issue and tag @tjayaramaraju or @Basti