Loading
Instrument triage_vulnerability UX SLI
What does this MR do and why?
Instruments the Triage and remediate a vulnerability customer journey SLI (https://gitlab.com/gitlab-org/gitlab/-/work_items/596316).
- Adds
config/user_experience_slis/render_vulnerability.ymlwithfeature_category: vulnerability_managementandurgency: async_fast(15-second apdex threshold). - Adds
Gitlab::Graphql::UxSliByOperationName, a mapper class that resolves a GraphQLoperationNameto a UX SLI ID. EE extends it to mapprojectVulnerabilities,groupVulnerabilities, andinstanceVulnerabilitiesto:render_vulnerability. - Adds
around_action :track_user_experience_sli_by_operation_nametoGraphqlController. This starts tracking before the query is parsed or executed, accurately capturing total user-perceived latency. It also scopes tracking to only the specific operations we care about, avoiding false attribution from other callers ofVulnerabilitiesResolver. - Removes the previous resolver-level instrumentation that only wrapped
fetch_vulnerabilities(a small fraction of the full request).
How does the apdex counter work?
gitlab_user_experience_total is incremented on every request completion
(success or error). gitlab_user_experience_apdex_total is incremented
only on successful completions, with success: true when the elapsed time
is within the urgency threshold (≤ 15 s for async_fast), and
success: false otherwise. The SLO is the ratio of satisfied requests.
How to set up and validate locally
- Enable Prometheus metrics in your GDK.
- Navigate to a project's Secure > Vulnerability report.
- Apply a severity or state filter.
- Query Prometheus for:
gitlab_user_experience_total{user_experience_id="render_vulnerability"}gitlab_user_experience_apdex_total{user_experience_id="render_vulnerability"}
- Confirm both counters increment on each page load and filter change.
MR acceptance checklist
- SLI YAML definition exists at
config/user_experience_slis/render_vulnerability.yml - Instrumentation emits
gitlab_user_experience_totalandgitlab_user_experience_apdex_totalwith correct labels - Tracking starts at the controller level (before query parsing) via
around_action, not inside the resolver - Operation name mapping is tested in isolation
- EE extension is in
ee/lib/ee/following GitLab EE conventions
Related https://gitlab.com/gitlab-org/gitlab/-/work_items/596316
Edited by Savas Vedova