Draft ideas in response to flapjack/flapjack.io#21 ... might generate some separete, more detailed / developer orented documentation from the below...
Things we also need to discuss here:
- Filters We probably want to discuss the low level of what the filters are each doing, but also describe at a higher level what the main behaviours are of the filters as a whole (some of the "filters" do more than just filter, eg the acknowledgement filter creates unscheduled maintenance). List of filters:
- acknowledgement
- base
- delays
- ok
- scheduled_maintenance
- unscheduled_maintenance
- Processor - we should point out which parts of the event->alert pipeline occur in which pikelets, given they can be split up to run in separate processes (and multiple instances of Processor, Notifier etc as needed). Processor handles:
- Event injestion (pops events off the 'events' redis list and creates Flapjack::Data::Event objects for each
- applies Filters that drop most events, create unscheduled maintenance, etc
- generates jobs on the Notifier's queue for any events not filtered out. At this stage the notification jobs are not contact specific.
- Notifier
- Pops notification jobs off the queue and generates Flapjack::Data::Notification objects for each
- Finds all contacts of the check's entity, or of the 'ALL' entity
- Finds all the mediums by which to transmit messages to each of these contacts
- Applies notification rules to each medium
- Generates separate "messages" for each of these mediums. Each message has a contact, a media type, and an address for that media type. If Ada Lovelace has three mediums (eg email, pagerduty, sms) then there'd be three messages generated for Ada for any checks she's interested in.