Skip to content

GitLab Next

Closed
Created by Sarah Waldner@sarahwaldner✨Developer

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:

  1. GitLab receives alert and checks the fingerprint field.
  2. IF fingerprint=NULL, default to gitlab fingerprint
  3. 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.

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Peter Leitzen