5. ❏ As far as I know, some monitoring systems
are configurable not to burst alerting.
❏ But, no fundamental solution applicable for
all alerting systems.
Remedy for this?
8. How “poloxy” works
In short, it’s just an alert proxy.
1. Monitoring systems send alerts to “poloxy”
instead of their recipients.
2. “Poloxy” API enqueues received alerts into
Queue.
3. “Poloxy” worker dequeues alerts every
minute or so, and delivers them to original
recipients.
9. Control Alert Frequency
❏ Alerts can be merged into one for each
recipient in each worker iteration (ex. 1
minute).
❏ Worker stores alerts history
=> “snooze” delivering repeating alerts for a
while.
❏ Categorize alerts in hierarchy by “grouping”
feature of “poloxy.”
❏ For visibility of service health
❏ For customizing alerts merging method
10. Grouping Alerts in Hierarchy (Sample)
root
generic
web
httpd
app
cpu
memory
alert
12. Status
❏ Public, but Under Development
❏ https://github.com/key-amb/poloxy
❏ Things to be done:
❏ API
❏ SMTP Support
❏ More alerts merging methods:
❏ ✔ per alert kind
❏ per group
❏ per address
❏ etc.
13. Technical Elements
❏ Sinatra for Web ’n API
❏ Sequel for ORM
❏ Mysql2 and SQLite3 are tested
❏ Worker is from scratch
❏ Redis as Queue, but will be integrated into
DB
❏ AdminLTE as UI Template