GitLab defined identification for generic alerts
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. In the scenario a user has not provided a mapping to define the gitlab alert identification field, GitLab needs a default alert identification schema.
This will be a Premium feature. Consolidating 100s or 1000s of alerts from different tools for different teams across an organization is a desire of a central IT led by a technical Director or VP. This will appeal to that central IT team that will be able to tie all of these alerts together much more easily.
Intended users
Further details
This work supports the direction of the Alert Management product category.
Proposal
Implement alert identification schema in the event we receive an alert that does not have an identifier. 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
fingerprintfield. - IF
fingerprint=NULL, default to gitlab fingerprint - IF
fingerprint!= NULL, use whatever value has been provided to identify that alert.
BEFORE this issue is implemented, 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
Note: As we always define a fingerprint for Prometheus alerts, this issue is valid for non-prometheus alerts only.