Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
We run multiple Kubernetes clusters that we monitor via a centralized Prometheus/Alert Manager, and we have that integrated with Alerta.
Our Prometheus configuration intends to be "generic enough" because we our cluster hosts multiple tenants in their own namespaces, and we don't want to update Prometheus every time we onboard (or offboard) a new tenant.
The problem is that our alerts get grouped under the same alert because the alert fields that are used for deduplication are event, resource and environment. According to the Prometheus/Alerta config repo the resource field in Alerta is grabbed from the instance field, which in our case holds the cluster node name. That causes alerts that belong to different tenants to be grouped under the same alert, which can be confusing unless you go to the alert details and look for the tags in order to find the affected Kubernetes namespaces.
Fixes # (issue)
N/A
Changes
Include a brief summary of changes...
Screenshots
N/A
Checklist
Collaboration
When a user creates a pull request from a fork that they own, the user
generally has the authority to decide if other users can commit to the
pull request's compare branch. If the pull request author wants greater
collaboration, they can grant maintainers of the upstream repository
(that is, anyone with push access to the upstream repository) permission
to commit to the pull request's compare branch
See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork