Move alert source-specific attributes onto payload class
What does this MR do and why?
Moves a few methods around alert integrations logic. This is a refactor only, and it does not modify any behavior.
This MR paves the way for !95827 (closed), so I can keep that MR smaller.
How to set up and validate locally
Send generic alerts
- In a project with maintainer+ permissions, nav to
Settings > Monitor > Alerts
to create/turn on an HTTP alert integration- Skip custom mapping fields for fastest integration creation
- Select 'Send test alert` to send an alert to your integration
{ "title": "This is a new test alert", "fingerprint": "fingerprint" }
- Visit
Monitor > Alerts
to see the new alert, and selectActivity
to see the system notes which are generated from new methods
Send recovery alerts
- Go back to
Settings > Monitor > Alerts
to send another test alert, and include the appropriate resolving attributes (end_time
for HTTP integrations){ "title": "This is a new test alert", "fingerprint": "fingerprint", "end_time": "2022-08-30T11:22:40Z" }
- Visit
Monitor > Alerts
to view your original alert -> it should be resolved & have new system notes under "Activity" tab
Send Prometheus alerts
- Alerts from prometheus can be sent to either a "Prometheus" integration, or a generic HTTP integration. They'll be processed the same either way.
- Firing prometheus payload:
{ "version" : "4", "groupKey": null, "status": "firing", "receiver": "", "groupLabels": {}, "commonLabels": {}, "commonAnnotations": {}, "externalURL": "", "alerts": [{ "startsAt": "2022-08-30T11:22:40Z", "generatorURL": "http://host?g0.expr=up", "endsAt": null, "status": "firing", "labels": { "gitlab_environment_name": "production" }, "annotations": {} }] }
- Prometheus recovery payload:
{ "version" : "4", "groupKey": null, "status": "resolved", "receiver": "", "groupLabels": {}, "commonLabels": {}, "commonAnnotations": {}, "externalURL": "", "alerts": [{ "startsAt": "2022-08-30T11:22:40Z", "generatorURL": "http://host?g0.expr=up", "endsAt": "2022-08-30T18:22:40Z", "status": "resolved", "labels": { "gitlab_environment_name": "production" }, "annotations": {} }] }
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