- "poloxy" is a proxy system that pools and proxies alerts to prevent monitoring systems from bursting alerts to recipients. It works by having monitoring systems send alerts to "poloxy" instead of recipients. "poloxy" then enqueues alerts into a queue and has a worker dequeue alerts every minute and deliver them to original recipients, merging duplicate alerts and preventing repeated alerts from being delivered too frequently. This allows customizing how alerts are merged and controlling the frequency of alerts received by each recipient.

1. Introduction to “poloxy”
- a proxy system for alerting -
@key_amb
In 西日暮里.rb 2016/4/28 #ninirb

2. Who am I ?
❏ @key_amb
❏ Software Engineer
❏ Serverside, Web
❏ https://github.com/key-amb
❏ https://rubygems.org/profiles/key-amb

3. Question
Have you ever received
thousands of e-mails
in one hour?

4. Sometimes, it does happen.
** This screenshot is just a mockup.

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?

6. “poloxy”
Pool and proxy your alerts.

7. Concept of “poloxy”

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

11. Dashboard

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

14. DEMO

15. Coming Soon

16. Thank you!