### Problem to solve 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) 1. Building integrations with a large percentage of these tools will take too long because of 1 1. 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 easily configure HTTP endpoints that receive alerts in their desired format. ### 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. The MVC of this tool will be located at Settings > Operations > Alerts. Users will be able to create multiple HTTP endpoints, name them, and add custom mappings to the endpoints if desired so that the endpoint will recieve alerts in their desired format. This is an easier to use alternative to the user having to modify alert formats in their monitoring tools. List of necessary functionality: 1. Ability to create multiple HTTP endpoints, name them, edit them, and delete them 2. Ability to add an optional custom mapping 3. Ability to view existing integrations as a list ### Designs **MVC proposal** | Default view | Integration type dropdown | HTTP endpoint integration type selected | Prometheus selected | Example integration added to the table | Multiple options added to the table | | ------ | ------ | ------ | ------ | ------ | ------ | | ||  |  |  |  | - If a user clicks the `edit` from the table, the form will load, fully populated with their previous selections - If a user clicks `delete` from the table, they will see a confirmation modal (shown below) - We want to work towards users being able to create multiple HTTP endpoint integrations. - Opsgenie will be maintained for the first iteration, but will be replaced in iterations 2 and 3 in favor of the new HTTP endpoint functionality. The hope is that people currently using the integration will use the HTTP Endpoint to build a proper integration with Opsgenie, so their alerts show up within GitLab. **Additional alerts, confirmation modals and tooltips** | Delete confirmation | Test alert sent | Active tooltip | Disabled tooltip | | ------ | ------ | ------ | ------ | |  |  |  |  | ### Further details This work supports the [Incident Management](https://about.gitlab.com/direction/monitor/debugging_and_health/incident_management/) direction.