User defined Alert identification
Problem to be solved
Teams responsible for maintaining IT services can easily receive hundreds (sometimes thousands) of alerts a day. To ensure the list of alerts in GitLab is manageable, and therefore useful, GitLab must be able to identify alerts to deduplicate them, organize them, and provide an event count. Additionally, it is necessary to associate alerts and incident issues that are created from the alerts to keep track of what is being addressed and what is new and needs to be looked at.
Identification is based on 1 or more fields in the alert payload which provides information about the problem that is occurring and the tool from which the alert came from. It is important to provide users the option to define this schema themselves since they have in-depth knowledge of their alerting systems.
Intended users
Further details
This work supports the direction of the Alert Management product category.
Proposal
Enable users to create mapping for how gitlab alerts are identified. This configuration should appear near where the alert endpoint is configured.
Since we're implementing both user and GitLab defined alert identification simultaneously, the logic will work as follows:
- GitLab receives alert and checks the
fingerprint
field. - IF
fingerprint
=NULL, default to gitlab fingerprint - IF
fingerprint
!= NULL, use whatever value has been provided to identify that alert.
BEFORE we have implemented #214557 (closed), we will simply NOT group alerts when the fingerprint
field = NULL.
- This is NOT something we are going to give users the ability to configure. This will be defined on the backend and function this way for all users.
- There will be no UI control at this time
- We will need thorough documentation for how this works