Notifications binding
🔗 Contents
Notifications binding for our modules are based on SignalFx detector rules severities.
We recommend best practices to choose the right severity for defined alerting rules depending on what it monitors and how serious the alert is.
for high priority alert waking up on call agent 24/7. Notification is sent to dedicated alerting tool like PagerDuty.
Often related to availability or saturation of a resource/service.
Similar to Critical but for incident which could wait to be resolved during business hours.
Also sent to alerting tool but with lower priority to avoid alert notification during graceful
period (i.e. the night).
It will also generate notification but not disruptive this time like a message on Slack channel or a simple email. The alert should and will be treated when agent is available without need to stop current tasks immediately.
Often related to performance degradation or proactive diagnostics.
Should not notify at all but log the alert in a low priority aggregator like a dashboard for proactive treatment or to help providing troubleshooting inputs in case of more important problem.
Often related to known and "normal enough" changes like the decrease of a cluster size.
(We would pick an higher severity if cluster is unhealthy but Warning is perfect for a
change which let the cluster fully healthy.
Must not notify at all and does not represent a change which could become a problem. It is a simple information which could help in troubleshooting scenario, that is all.
Often used for debugging purpose or to notice an event like the start of a backup.
