Fingerprints

Fingerprints serve several important purposes in the context of alerting within Keep:

​

De-Duplication

Alert fingerprints are used to prevent the duplication of enrichments/workflows triggering for the same underlying alert. When Keep receives an alert, it calculates a fingerprint based on the configured fields declared within the Provider. If two alerts have the same fingerprint, Keep considers them to be duplicates and will present one of them. This helps reduce alert noise and prevent unnecessary workflow triggers/enrichments.

​

Grouping

Keep uses alert fingerprints to group related alerts together. Alerts with the same fingerprint are considered to be part of the same group, indicating that they are triggered by the same underlying condition or problem. Grouping alerts makes it easier for operators to understand relations between different alert-sources, the root cause of an issue and take appropriate action faster.

​

Silencing

Alert fingerprints are used in third-party tools to manage silences/mutes. Silencing allows operators to temporarily suppress alerts with specific fingerprints, providing a way to acknowledge and handle known issues without generating additional notifications/triggers.

​

Visualization

Alert fingerprints can also be used for visualization and analysis purposes. They help in tracking the history and status of alerts over time and provide a means to correlate alerts with specific conditions or changes in the monitored system.

The process of generating a fingerprint involves hashing the fields configured in the provider and their values associated an alert instance. This results in a fixed-length, hexadecimal string that uniquely identifies that alert. When Keep receives/gets an alert, it calculates the fingerprint for each alert to determine if it should trigger a workflow, be grouped, or is silenced.

In summary, Keep alert fingerprints are essential for managing and organizing alerts in every third-party system. They help prevent duplicates, group related alerts, enable silencing, and facilitate analysis and visualization of alert data, ultimately aiding in the effective operation and maintenance of monitored systems.

​

Examples

This is the base provider class implementation for fingerprint fields:

class BaseProvider(metaclass=abc.ABCMeta):
    OAUTH2_URL = None
    PROVIDER_SCOPES: list[ProviderScope] = []
    PROVIDER_METHODS: list[ProviderMethod] = []
    FINGERPRINT_FIELDS: list[str] = []

This is Datadog’s provider implementation for fingerprint fields, where we calculate fingerprint based on the event groups and monitor id, as an example:

class DatadogProvider(BaseProvider):
    """
    Datadog provider class.
    """

    PROVIDER_SCOPES = [
      ...
    ]
    PROVIDER_METHODS = [
      ...
    ]
    FINGERPRINT_FIELDS = ["groups", "monitor_id"]