Multiple HTTP Endpoints
### Release Notes Alert integrations are a critical part of your Incident management workflows, which is why it is important for you and your team to have complete control over the endpoints and auth tokens. The last thing you want is for another team to take down your alerting because they reset the auth token for an alerting endpoint and didn't tell you! Set up multiple HTTP endpoints for all of your monitoring tools and completely own them as a team. Documentation: https://docs.gitlab.com/ee/operations/incident_management/alert_integrations.html ### Problem to solve Teams needs to be in charge of their monitoring and incident management processes. It is common that teams need to maintain specific access to incidents and monitoring tools. This means that they will need their own endpoints with unique credentials so that they can have total control over their alerting. Additionally, for a single team, it makes sense to have one endpoint per tool with credentials that they can reset independent of other tools. This lowers risk and provides more granular control over alerting for each individual tool. ### Intended users * [Allison, Application Ops](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) ### User experience goal A user can create, name, and view multiple HTTP endpoints with unique credentials in GitLab. ### Proposal Enable the creation and storage of multiple HTTP endpoints. In the UI, users can select HTTP endpoint from the list to create a new one. There will be a text input box for naming the integration. Below the credentials, will be the current test alert functionality Clicking **Save** will add the new integration to the integrations list. ### Designs | Default page view | Dropdown with existing options | HTTP endpoint selected | Prometheus selected | New integration successfully added message | Test sent | | ------ | ------ | ------ | ------ | ------ | ------ | | ![MVC](/uploads/0857eeb824011ee6e8af030ae44967ab/MVC.png) | ![Dropdown](/uploads/a9b31b3a2ed6b2a5bfe4c4da4733fe0c/Dropdown.png) | ![MVC_-_HTTP_endpoint_selected](/uploads/47066744cb361b6a8d2b6540c70d18de/MVC_-_HTTP_endpoint_selected.png)| ![MVC_-_Prometheus_selected](/uploads/13f07dbd2c74faa5989a895c41f341de/MVC_-_Prometheus_selected.png) | ![Save_confirmation](/uploads/78788237ab91ae4e9aafe4c66da542bc/Save_confirmation.png) | ![Test_sent](/uploads/4b855cd445740c9e84d792aa10fc5efd/Test_sent.png) | As part of this work we'll update the layout of the Prometheus option to better align with what's being shown in the new HTTP Endpoint section. Essentially, this just involves breaking the steps up into numbered items. When this work is complete, the current Opsgenie integration will be replaced with the ability to add a new HTTP endpoint. [Figma file](https://www.figma.com/file/ngP46IcxTj68Wwlmr8Jolq/Custom-integrations-gitlab-com-and-217766?node-id=351%3A16623) ### Further details This work supports the [Incident Management](https://about.gitlab.com/direction/monitor/debugging_and_health/incident_management/) direction.
epic