Alert deduplication can help you reduce alert noise by organising and grouping relevant alerts. This also provides easy access to similar alerts when needed.

For each service, you can define your rule for deduplication.

You can set this up by going to your Squadcast account

• Go to the relevant service
• Click on the options dropdown
• Choose De-duplication rules

• Choose Alert Source from the Dropdown

By default, when a new rule is being created, a user is prompted to use the drop-down blocks for convenience in-order to create a deduplication rule. As you build the expression from these drop-downs, simultaneously you can see the corresponding deduplication expression raw string for the same, just to ensure that you are building the right rule.

The drop-down blocks are beginner friendly for sure, but they aren't as flexible as raw string method.
If you want more flexibility while building your expressions, you may opt anytime to switch to the raw string mode by clicking the edit button as shown.

The method of specifying one rule is independent from others in the same service as well.
So, for the same service, you may have few rules in drop-down block mode, few in raw-string mode.

📘

NOTE

1. Once you opt for the raw-string method, you can't revert back to the drop-down blocks for that specific rule.

2. The drop-down blocks support 2 major type of expression matchings:

i. Match corresponding field of incoming payload with a past payload (only == operation is allowed for this using is same as comparator from drop-down)

ii. Match a particular field of incoming payload against a constant literal value (using ==, <=, >= etc,.)

In-case, if you want something else apart from these 2 cases, then prefer using the raw string alternative.

3. The drop-down blocks only support logical AND operator between 2 expressions. If you want to have a logical OR operation between 2 expressions, then you would have to create a new de-duplication rule instead and have the copy over the same time window for the other rule.

Then, select a time window for which the rule holds true. The maximum time window allowable is 2 days, i.e. 48 hours.

📘

Time Window

During the time window set, incidents that occur are compared against all incidents that come in during that time period and will then get deduplicated against the first incident that it matches with.

The rules will be checked against all the incidents based on the time window set in place.

The count of events deduplicated against an incident will be shown in the incident dashboard and the incident details page.

Rule Execution Priority

The rules will be checked against all the incidents based on the time window set in place.

You can add as many rules by selecting the "Add rule" button below. The deduplication will be true for the first rule that matches in the list of rules added by you.

So, you can rearrange the rules to prioritize them suitably by using the Move Up and Move Down buttons on the top-right corner of the Change Execution Priority segment.

Deduplicate across Multiple Alert Sources

We can see alert payloads of past events from different active alert sources for the service by selecting the respective alert source from the dropdown in the right panel.

🚧

Note

By default, the Deduplication Rule would be executed across all the Active Alert Sources for the Service unless the rule specifies otherwise .

If you want to deduplicate across specific active alert sources, you can specify this explicitly in your rule to ensure that it is executed accordingly.

For example, if there has been an event triggered via alert source sentry and there is another alert triggered via jira-cloud indicating the same incident, then you can de-duplicate them by using a rule which will look something like:

(past_source == 'sentry' && source == 'jira-cloud') && <your_de-duplication_rule>

This will have to be configured as a raw string in the Deduplication Expression textbox.

Syntax for Writing Rules (For Raw String method)

The rule engine supports expressions with parameters, arithmetic, logical, and string operations. You can also check out this link to get an idea of all the expression types accepted in Squadcast.

• Basic expression: 10 > 0, 1+2, 100/3
• Parameterized expression: past.metric == current.metric
  The available parameters are past, current, event_count, past_source, source, past_tags, tags, past_incident.
  • past : This parameter contains the JSON payload of the previous incident which the current event is compared with.
  • current : This parameter contains the JSON payload of the incoming event which will be compared with the past incidents' JSON payload.
  • event_count : This denotes the number of deduplicated events for a given incident
• Regular expression: re(past.metric, "disk.*")
  • past_source: This denotes the associated alert source for the past incident that we are deduplicating against.
  • source: This denotes the associated alert source for the current / incoming event. (Is usually matched against the past_source)
  • past_tags: This denotes the tags associated with the past incident that we are deduplicating against.
  • tags: This denotes the tags associated with the current / incoming event. This is calculated using Tagging Rules.
  • past_incident: The parameters of the past_incident object is as follows
    + message: This is the Incident Title of the past incident.
    + is_triggered: This denotes the state of the past incident. This will hold true for Triggered incidents.
    + is_acknowledged: This denotes the state of the past incident. This will hold true for Acknowledged incidents.
    + is_suppressed: This denotes the state of the past incident. This will hold true for Suppressed incidents.
    This can be used to check if a particular JSON payload field matches a regular expression.
• Parsing JSON content: jsonPath(payload.message, "a.b.c")
  This can be used to parse JSON formatted strings and get the jsonPath from the resulting JSON object

📘

Use Case for event_count

This can be used in scenarios where you don't want to deduplicate more than n number of events to a particular incident.

Examples

For a sample content shown in the right panel of the configuration space

{
  "event_count": 5,
  "past": {
    "issue_description": "bug - 2",
    "issue_id": "10029",
    "issue_key": "HYD-30",
    "issue_labels": [],
    "issue_link": "http://13.233.254.18:8080/browse/HYD/issues/HYD-30",
    "issue_priority": "Medium",
    "issue_summary": "bug - 2",
    "issue_type": "Bug",
    "project_id": "10000",
    "project_key": "HYD",
    "project_name": "hydra"
  },
"past_source": "jira-server",
  "source": "jira-plugin",
  "past_tags": {
       "ticket_type": "bug",
  },
 "past_incident": {
    "message": "Bug-2",
    "is_triggered": false,
    "is_suppressed": false,
    "is_acknowledged": true
  }
}

Use Case
For any incoming alert, if

• The metric matches the regular expression ^disk.*
• The past incident metric and the current event metric are the same
• The past incident host and the current event host are the same
• The current disk usage value is less than 60%
• The context value tag is same

Rule
(past.metric == current.metric) && re(current.metric, "^disk.*") && (past.host == current.host) && (current.value < 60) && jsonPath(past.tags, "context.value") == jsonPath(current.tags, "context.value")