### Problem to solve Users should be able to set alerts on metrics defined in dashboard yml files in the project. The ability is available for gitlab-defined "common" metrics & custom metrics created in the UI, but not yet for yml-defined metrics. As a first step, we should look at bringing metrics defined for `area-charts` up to parity with existing metrics. Metrics for other panel types should come in another iteration. - Open questions: - When do we want to persist metrics? Pipeline? - Should this step include validation & fail the build for invalid dashboards? - Do we want to clean-up project metrics which are no longer present in a dashboard? Or do they live forever? - Do we want to perform reconciliation between custom metrics created in the UI & dashboard yml-defined metrics? ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal Technical Implementation Proposal: - Refactor `CommonMetricsImporter` to support project-defined metrics; Include a follow-up step that deletes removes project-defined metrics (probably distinguishing from custom metrics by the presence of the identifier from the yml) - Call updated importer from pipeline? (This is the part I'm fuzzier on and has potential for scope creep) - Update `Metrics::Dashboard::Processor` stages to account for project-defined dashboard metrics - Test alerting (Should work out of the box, but we'll need to test) First iteration: - Should the persistence step include validation & fail the build for invalid dashboards? No. - Do we want to clean-up project metrics which are no longer present in a dashboard? Or do they live forever? No, they are removed. - Do we want to perform reconciliation between custom metrics created in the UI & dashboard yml-defined metrics? No. If a metrics has been defined in both spots, the user can do any cleanup they want to. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> - integration tests as usual - [end to end test](https://gitlab.com/gitlab-org/quality/testcases/-/issues/663) - consider to trigger `package-and-qa` on MR to ensure existing end-to-end tests are not breaking (an alert test is defined but only for common metrics) ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references ### Status | Work | Status | MRs | Estimated Effort | Notes | ------ | ------ | ------ | ------ | ------ | | Groundwork | Complete | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35566, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38237, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35912 | - | | [Dashboard Validator](https://gitlab.com/gitlab-org/gitlab/-/issues/230537) | Complete | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36385, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38237, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37518, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38847| - | | [Dashboard Importer](https://gitlab.com/gitlab-org/gitlab/-/issues/230539) | Complete | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37773 | - | | [Hook up validator and importer](https://gitlab.com/gitlab-org/gitlab/-/issues/230540) | Complete | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39658 | Deliverable | Most of the heavy lifting was done building out the dashboard validator and importer. There is some uncertainty on where to hook repository changes but this will mostly be just gluing together code from previous MRs. | Verify alert flow | In Dev | | Research/Possible Deliverable | Potentially only a review issue. We want to make sure we have our bases covered when creating/updating/deleting metrics in that they flow changes to any dependent models (PrometheusAlerts etc).