[🐛 Bug]: Prometheus provider ignores custom fingerprint fields for dedupe

[poandlsl]

Describe the bug
It appears that the Prometheus provider ignores custom fingerprint fields set in the deduplication rule and generates the fingerprint hash based on the alertname alone.

To Reproduce
Steps to reproduce the behavior:

1. Provision or manually add a Prometheus provider. (with pulling enabled)
2. Modify default deduplication rule for Prometheus provider to use multiple labels for Fields to use for fingerprint.
3. Observe alerts with different values for selected fingerprint labels are still deduplicated based on alert name alone.

Expected behavior
Prometheus provider should generate a unique fingerprint hash based on labels configured in deduplication rule.

Additional context

Provider provision config:

{
  "keepPrometheus": {
    "type": "prometheus",
    "authentication": {
      "url": "https://prometheus.dev1.domain.com",
      "verify": false
    },
    "deduplication_rules": {
      "prometheus_default_dedupe": {
        "description": "This is the default deduplication rule for Prometheus alerts",
        "fingerprint_fields": [
          "labels.alertname",
          "labels.env_dc",
          "labels.group"
        ],
        "full_deduplication": false
      }
    }
  }
}

Note identical fingerprint hash for alerts with different group labels:

$ echo -n 'NodeLowDiskSpace4Hours' | sha256sum
6211e97de90695be41b49c773306001204872a6ebb36f4aa72a5bbd998ce7ac5  -

[dosubot]

Hi @poandlsl! I'm Dosu and I’m helping the keep team.

This is a confirmed bug: the Prometheus provider currently ignores custom fingerprint fields set in deduplication rules and falls back to using only the alertname for fingerprinting, even when multiple fields are configured. This causes alerts with different label values to be deduplicated as if they were the same alert, matching your observations and config. The root cause is that the provider does not dynamically apply the deduplication rule’s fingerprint_fields when generating fingerprints, despite Keep’s general support for this feature across other providers. There are open issues tracking this limitation, and a fix is planned but not yet merged [issue #4766, docs].

If you need a workaround before a fix lands, you may be able to manually patch the provider logic to use the correct fingerprint fields, as described in the linked issue. Otherwise, keep an eye on the repo for updates.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}