alerta-contrib
alerta-contrib copied to clipboard
Add remapper plugin
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...
- Add new "Remapper" plugin which allows remapping alert fields values according to given mapping rules passed via configuration.
Screenshots N/A
Checklist
- [x] Pull request is limited to a single purpose
- [x] Code style/formatting is consistent
- [x] All existing tests are passing
- [x] Added new tests related to change
- [x] No unnecessary whitespace changes
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