You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the below flow, there is theoretical inhibition that says “when alert2 is firing, alert1 should be suppressed”
Prom: alert1 fires
AM gets alert1, routes to PD
PD receives alert1
Prom: alert2 fires
AM gets alert2
AM suppresses alert1
AM routes alert2 to PD
PD receives alert2
PD now has two alerts
Alert1
Alert2
Prom: alert1 resolves
AM resolves alert1
PD receives no notification as the alert is suppressed
PD: alert1 becomes orphaned
Prom: alert2 resolves
AM resolves alert2
PD receives resolved notification for alert2
PD resolves alert
PD retains alert1 that is now orphaned
This is undesirable at scale where our pager/dashboards are becoming overwhelmed with orphaned alerts that can require extensive investigation to manually mark as resolved.
What did you expect to see?
When an alert that has fired and has been routed externally becomes inhibited, its resolved signal bypasses inhibition to notify the external source that it is resolved.
What did you see instead? Under which circumstances?
Add an additional boolean configuration option similer to that of send_resolved.
# Whether or not to notify about resolved alerts.
[ send_resolved: <boolean> | default = true ]
# whether or not to notify about resolved alerts whom were firing prior to being inhibited
[inhibited_send_resolved: <boolean> | default = false ]
Desired outcome: Any alert that has fired and been sent externally should be able to send their resolved status regardless of that alerts state (active,supressed)
How it could work:
alert1 fires
AM sends external notification
alert2 fires
AM sends alert2 external notification
AM inhibits alert1
alert1 resolves
Here we could explore two options:
If alert1 resolves AND notified externally prior to becoming inhibted:
-> send resolve regardless of inhibited status.
^ de-couples alert state
If alert1 resolves AND notifiied externally prior to becoming inhibited:
-> store resolved state in MEM
-> send resolved state when inhibiter resolves
^ coupled alert state
Not knowing the codebase well, I prefer 1 as it is a truer representation of the state of the system.
The text was updated successfully, but these errors were encountered:
What did you do?
Prom = Prometheus
AM = Alertmanager
PD= PagerDuty
In the below flow, there is theoretical inhibition that says “when alert2 is firing, alert1 should be suppressed”
This is undesirable at scale where our pager/dashboards are becoming overwhelmed with orphaned alerts that can require extensive investigation to manually mark as resolved.
What did you expect to see?
When an alert that has fired and has been routed externally becomes inhibited, its resolved signal bypasses inhibition to notify the external source that it is resolved.
What did you see instead? Under which circumstances?
Orphaned alerts as per description.
Environment
OpenShift 4.[7,8,9].*
Feature Request
Add an additional boolean configuration option similer to that of
send_resolved
.Desired outcome: Any alert that has fired and been sent externally should be able to send their resolved status regardless of that alerts state (active,supressed)
How it could work:
Here we could explore two options:
If alert1 resolves AND notified externally prior to becoming inhibted:
-> send resolve regardless of inhibited status.
^ de-couples alert state
If alert1 resolves AND notifiied externally prior to becoming inhibited:
-> store resolved state in MEM
-> send resolved state when inhibiter resolves
^ coupled alert state
Not knowing the codebase well, I prefer 1 as it is a truer representation of the state of the system.
The text was updated successfully, but these errors were encountered: