Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VMAlertmanager: possibility to customize default matcher labels #1096

Closed
romainlaurent opened this issue Sep 10, 2024 · 3 comments
Closed

VMAlertmanager: possibility to customize default matcher labels #1096

romainlaurent opened this issue Sep 10, 2024 · 3 comments
Labels
question Further information is requested waiting for release The change was merged to upstream, but wasn't released yet.

Comments

@romainlaurent
Copy link

Hey folks

I have my Alert Manager running in a cluster, and it's reading VMAlertmanagerConfig from different namespaces. I could add the namespace label through VMAlert, but the metrics are coming from another cluster, and the namespace would be overwritten even though it's needed in the rule.

Would it be possible to customize the default label matcher by configuring the VMAlertmanager operator? We could change it here.

I'd be happy to implement this change if you're okay with it.

@f41gh7
Copy link
Collaborator

f41gh7 commented Sep 12, 2024

Hello,

I don't think, that changing default matcher is a good idea. First of all, it was designed for SaaS like metrics stack deployment. When scraping, alerting and notification configurations created at the same namespace. In this case namespace label enforced at scraping and notification configurations.

I'd suggest to disable namespace matcher and add needed matchers manually at VMAlertmanagerConfigs.

Maybe we could add some sort of globalVMAlertmanagerConfigMatchers array at VMAlertmanager side.

Like:

kind: VMAlertmanager
spec:
  enforcedTopRouteMatchers:
   - {namespace != ""}

But it doesn't look like good solution to me.

@f41gh7 f41gh7 added the question Further information is requested label Sep 12, 2024
@romainlaurent
Copy link
Author

The solution you propose seems to be a good one.
It would allow for better control over the default matchers.

To provide context, I have no control over the VMAlertmanagerConfigs, which are configurable by the user.
I do have control over the VMAlert, where I can set up static labels, and the VMAlertmanager (knowing the alert manager is shared among multiple users).

This feature would help me significantly to avoid alert collisions between users and undesired label overrides.

f41gh7 added a commit that referenced this issue Sep 23, 2024
It allows to enforce some matchers for VMAlertmanagerConfigs.

Related issue: #1096

Signed-off-by: f41gh7 <[email protected]>
@f41gh7 f41gh7 added the waiting for release The change was merged to upstream, but wasn't released yet. label Sep 23, 2024
@f41gh7
Copy link
Collaborator

f41gh7 commented Sep 29, 2024

Feature added at v0.48.3 release.

With new setting spec.enforcedTopRouteMatchers it's possible to enforce matchers for all VMAlertmanagerConfig for particular `VMAlertmanager.

kind: VMAlertmanager
spec:
  enforcedTopRouteMatchers:
  - {namespace!=""}

Must enforce namespace label to present at alert to be able routed into VMAlertmanagerConfig.

@f41gh7 f41gh7 closed this as completed Sep 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested waiting for release The change was merged to upstream, but wasn't released yet.
Projects
None yet
Development

No branches or pull requests

2 participants