Replies: 17 comments 10 replies
-
That's kind of the point of the feature, otherwise it's possible that alertmanager configs in different namespaces conflict and Alertmanager won't be able to start. |
Beta Was this translation helpful? Give feedback.
-
Perhaps I'm in the minority but the feature I really cared about was using secret refs. Regardless, do you see any reason why current behavior can't be the default and provide the ability to override? One other thought I haven't tried is deploy only receivers via the object and, when necessary, deploy the route via the normal secret? |
Beta Was this translation helpful? Give feedback.
-
#3737 has the same problem: being able to specify a default on the alertmanager resource would be great |
Beta Was this translation helpful? Give feedback.
-
Doing just receivers in the As there are no secrets in the routes (at least for me, very much a prometheus newb,) I put them back in the secret. Since we use kustomize I should be able to put the routes in plaintext in git and use a secret generator (without the hash) to create the I suppose my issues are resolved but I have two semi-contradictory thoughts on this request: My interpretation of the choice to make namespace a default is that a Edge cases are inevitable given so many companies. I think the ability to turn off the namespace label (while leaving it as the default) is still preferable. If I understand the proposed solution in #3737 (which I definitely might not,) putting
|
Beta Was this translation helpful? Give feedback.
-
Actually, maybe doing only receivers only semi works? If you make a route in the
|
Beta Was this translation helpful? Give feedback.
-
I also tried using the AlertmanagerConfig CRD solely for the benefit of using SecretRefs in receivers. Being able to due that would significantly simplify our Alertmanager configuration. Currently, we generate a configmap with the config with the secrets templated, use an encrypted Secret with just the secret values, and run a small controller to bind the template with the real value, and update a Secret with the contents. All this was necessary in order to use a GitOps-based deployment process. This new CRD doesn't work for us. Our Alertmanager configuration is centrally managed, our alerts often do not include a namespace, and we have many namespaces which should all have the same Alertmanager routes and receivers. |
Beta Was this translation helpful? Give feedback.
-
I've worked my way around most of it but it's proven to be tough.
|
Beta Was this translation helpful? Give feedback.
-
I think this is the same feature as requested in #3737? |
Beta Was this translation helpful? Give feedback.
-
No concrete numbers but in general, Alertmanager can cope with quite complex routing configuration: |
Beta Was this translation helpful? Give feedback.
-
Another GitOps follower here who just wanted to use this for the secret ref functionality! Spent half a day trying to implement in jsonnet only to find I'd have to duplicate all our routes and receivers in all namespaces just so I can inject an OpsGenie API key into the config. I think we're gonna have to go back to storing the whole thing in our nasty jsonnet -> git-crypted Secret -> SealedSecret workflow now :( Would really love the ability to do this sometime in the future. |
Beta Was this translation helpful? Give feedback.
-
What I found extremely frustrating and irritating: When you add an AlertmanagerConfig, it set's the namespace as a filter. But when you add a PrometheusRule to the same namespace, it does not add a corresponding label! I understand the logic behind that, but it just cost me around two days to figure it out. |
Beta Was this translation helpful? Give feedback.
-
Same problem here :- ( Setting my hopes on PR 4034 |
Beta Was this translation helpful? Give feedback.
-
Fully agreed with @muffl0n. @simonpasquier |
Beta Was this translation helpful? Give feedback.
-
Based on what is the match directive set? Is it based on which namespace the Alertmanager configured exists in, or something else? |
Beta Was this translation helpful? Give feedback.
-
No idea why the design like this. We have prometheusrules created from different namespaces, and we want to have a unique alertmanagerconfigs to set alert notify routes. But now , it seems it's impossible. Really ridiculous. |
Beta Was this translation helpful? Give feedback.
-
this part here crd-alertmanagerconfigs.yaml#L4382-L4384 doesn't make sense:
because there's some alerts without namespace labels, but with other labels and forcing resource's namespace match will lead to ignore other match conditions based on some other labels: example, by applying below alertmanagerconfig spec:
is resulting to the below alertmanagerconfig:
i want to remove the namespace matcher and keep only defined ones because there are some alerts that don't contain a namespace label. |
Beta Was this translation helpful? Give feedback.
-
Setting |
Beta Was this translation helpful? Give feedback.
-
What did you do?
I created an
AlertmanagerConfig
and noticed it is adding a matcher fornamespace
. Is there some way to turn this off? What if there is no namespace label? What if the namespace is under a different label? What if I want it to be for all namespaces?Did you expect to see some different?
I think I sort of understand why this exists, but curious if there's any way to turn this off.
Environment
Prometheus Operator version:
v0.44.0
Kubernetes version information:
v1.16.15-gke.4300
Kubernetes cluster kind:
gke using terraform
Manifests:
Anything else we need to know?:
Beta Was this translation helpful? Give feedback.
All reactions