GitLab defined alert identification (#214557) · Issues · GitLab.org / GitLab

GitLab 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. 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 fingerprint field.
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

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

### 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.

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)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)

### Further details

This work supports the direction of the [Alert Management](https://about.gitlab.com/direction/monitor/debugging_and_health/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.
1. IF `fingerprint`=NULL, default to gitlab fingerprint
1. 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

### Permissions and Security

### Documentation

<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html

* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

### 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 May 18, 2020 by Sarah Waldner

Discussion
Designs