### Problem to solve As stated in the [parent epic](https://gitlab.com/groups/gitlab-org/-/epics/3362), enterprises are already invested and entrenched in a suite of monitoring tools, moreover, there are hundreds of monitoring tools in market today. These emit alerts with unique payloads differing in format and content. GitLab's Alert Management tool needs to be able to consume and aggregate alerts from any tool. Other incident management tools have invested in building and maintaining individual integrations so that they can consume proprietary alerts from all of these tools. This is not a viable solution for GitLab because: 1. Our team focused on solving this problem in market is small (there are entire companies working on this) 2. Building integrations with a large percentage of these tools will take too long because of 1 3. Maintaining all of these integrations would be a lot of on-going work To overcome these limitations, we need to create a simple repeatable process by which customers can integrate any tool with GitLab. If we can create a service that enables users to easily translate proprietary alerts to the GitLab format so that GitLab can consume and display the alert in the UI, we can quickly catch up to other incident management tools in market. ### Intended users * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) ### User experience goal An operator can integrate any tool with the service with little to no code. ### Proposal Create a tool that parses alerts and allows users to map alert attributes to GitLab alert fields. Users can create new integrations and save them for each tool they want to integrate. Each time they create a new integration, that integration will get a new endpoint and unique auth token. ### User Experience 1. User clicks **New Integration** 2. User imports example payload for alert 3. GitLab parses and displays the alert payload in a format that allows users to see each attribute individually (example: If the format of the alert is nested, GitLab should parse and display all fields in a single layer of key:value pairs - e.g. "alert.details.start_time": "2020-06-13T12:26:28Z") 4. User maps fields from their alert to GitLab's fields 5. User can add additional fields to GitLab alert and map to them 6. User can name the integration 7. User can edit the integration 8. User can delete the integration FUTURE IDEA: These integrations could also be made available to the wider community.  Gitlab could start by creating a few integrations for highly used tools and documenting these examples. ### Designs The full flow is visible in [Figma](https://www.figma.com/file/ngP46IcxTj68Wwlmr8Jolq/Alert-integration-builder-gitlab-com-and-217766?node-id=0%3A1). There is also a [prototype](https://www.figma.com/proto/ngP46IcxTj68Wwlmr8Jolq/Custom-integrations-gitlab-com-and-217766?node-id=111%3A2390&scaling=min-zoom) available to show how the different integration types would work. The designs account for all the existing functionality (REST endpoint, Prometheus and Opsgenie integrations) and planned updates (email integration). In addition, they include the new "custom" workflow: | Initial decision point, between GitLab and Opsgenie | Opsgenie option | Custom integration type selected | Configuration step part 1 | Configuration step part 2 | Testing/finalizing step | Success alert and table update | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | |  |  | |  || | | ### Further details This work supports the [Alert Management](https://about.gitlab.com/direction/monitor/debugging_and_health/alert_management/) direction. ### Permissions and Security ### Documentation ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? 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? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### 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. --> ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> ### Links / references