Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,824
    • Issues 43,824
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,413
    • Merge requests 1,413
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #214557
Closed
Open
Created Apr 15, 2020 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

  • Devon (DevOps Engineer)
  • Sidney (Systems Administrator)

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 Jun 17, 2020 by Peter Leitzen
Assignee
Assign to
Time tracking