Add support for Prometheus as HTTP alert integrations
What does this MR do and why?
Related issue: Allow Prometheus' metrics dashboard and incomin... (#338838)
Summary
- This MR is preparation for migrating
Integrations::Prometheus
records to the table forAlertManagement::HttpIntegration
. - There are no user-facing changes.
- This enables us to separate alerting from metrics, so we can remove the Metrics Dashboard feature in %16.0.
Changes in this MR
type_identifier
attribute to HTTP integration table/model
Add - Add column
type_identifier
toalert_management_http_integrations
table - Add
type_identifier
enum toAlertManagement::HttpIntegration
model, with values for only:http
and:prometheus
- Notable: For backwards compatibility, the
Integrations::Prometheus
records will be migrated with a legacy identifier, so we can still accept alerts to the same endpoints, even though the URL doesn't match the default format for new integrations.
- Notable: For backwards compatibility, the
Modify CRUD services to accommodate new attribute
- Add support to
CreateService
for the new attribute, defaulting to:http
whentype_identifier
is absent- Notable: Multiple generic HTTP integrations is a GitLab Premium feature, but Prometheus integrations were limited to 1 per project wholesale. That was an artifact of piggy-backing on
Integrations::Prometheus
. This MR changes the limit. It's now 1 HTTP integration per type for GitLab Free. So the behavior is the exact same for GitLab Free, but expanded for GitLab Premium.
- Notable: Multiple generic HTTP integrations is a GitLab Premium feature, but Prometheus integrations were limited to 1 per project wholesale. That was an artifact of piggy-backing on
- Add support to
UpdateService
to change the type of integrations (accounting for licensed feature availability) - Add support to
DestroyService
to remove prometheus type integrations- Notable:
-
Integrations::Prometheus
records can't be deleted once they've been persisted. And we plan to create a corresponding record inalert_management_http_integrations
for eachIntegrations::Prometheus
ever configured to accept alerts. - If a corresponding http_integration does not exist, it means either:
-
- the migration hasn't been completed yet, or
-
- the integration was deleted.
-
- To rule out
#2
, I opted to prevent deletion of the legacy prometheus integrations from the HTTP integrations table. This lets us use presence checks to determine which record should act as SSOT for that integration. Then we aren't switching over too early before the migration has run or trying to keep the state between the records in sync.
-
- Notable:
Why no new index?
- There are only ~1500
alert_management_http_integrations
on dot-com, so the scale is decently small. - Searching for an HTTP integration is always scoped by project. Queries beyond that are a mix-n-match of searching by
active
,endpoint_identifier
,type_identifier
, and/orid
. GitLab Free projects will also have a max of 2alert_management_http_integrations
, so those definitely won't be benefitted by a new index. - The most common query (alert ingestion) is already covered by
index_http_integrations_on_active_and_project_and_endpoint
, but the other queries should be very infrequent, as this configuration is highly unlikely to change often. And some will be removed with #409734, so we won't have the queries for a long time.
Why no feature flag?
I initially started development with a feature flag, but the diff was very convoluted. So for this change, I think it's safer to have a clean diff, clear expectations of behavior, and backwards compatibility without the flag.
What about all the other stuff this needs?
- This MR: Add support for Prometheus as HTTP alert integr... (!120046 - merged)
- Next backend MR: Support custom mappings for Prometheus integrat... (!120055 - merged)
- Required backend MR: Draft: Allow creation of Prometheus-type HTTP i... (!120197)
- Required backend MR: Migrate prometheus integrations to HTTP alert i... (!119847 - merged)
- Follow-up frontend MR: TBD - adjusting UI fields for alert integration form
- Docs MR: TBD
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Sarah Yasonik