Inhibits should be per-route rather than global

[brian-brazil]

Inhibits have the potential for accidentally affecting far more alerts than is desired, particularly in environments where more than one team is sharing the alertmanager (and we'll ultimately encourage one set of alertmanagers per company).

Accordingly it'll be safer for inhibitions to be per-route, and likely also easier to work with.

[matthiasr]

I don't think this will work out well.

It is still necessary to create global sciences – e.g. if I perform a maintenance that I know will cause phony alerts; I can't track down which routes that would go down.

An alert may go to more than one route, how would that be handled?

And finally, "silences per route" introduces yet another level of reasoning and makes silences even harder to understand. This will encourage simply silencing everything for a route, because "it's only our own stuff".

We should make it easier to understand and design silences of the correct scope, not artificially limit the scope along some dimension.

[brian-brazil]

It is still necessary to create global sciences – e.g. if I perform a maintenance that I know will cause phony alerts; I can't track down which routes that would go down.

Inhibits are about firing alerts preventing other firing alerts, I'm not seeing how silences come into it.

I think you're confusing inhibits and silences.

[matthiasr]

Indeed I am. You see, too many layers! No opinion either way from me then, since I haven't worked with inhibits too much yet.

[grobie]

👍 It confused me to see inhibit_rules being a global setting.

[oleg-glushak]

+1