This is a list of information that is collected by Stork Server through Stork Agent.
Each piece has some change frequency and user expectancy regarding freshness i.e. expected refreshing rate.
This is a list of data pullers implemented in Stork Server. Each one pulls some kind of data from Stork Agents.
BIND 9 Stats Puller
Kea Stats Puller
Kea Hosts Puller
Kea Status Puller
Machine & App State Puller (new)
Blaster is a module of Stork server that is responsible for collecting events and dispatching them to subscribers.
Event is an information about some change in the system. It can be New Network discovered in Kea or New Machine that was added to Stork server.
Subscriber is a particular web browser. It registers for given collection of events based on provided criteria. Subscriber receives stream of events from Blaster. This events in web browser may result in updating some parts of UI.
graph LR P1[Kea Stats Puller] --> A4 P2[Kea Status Puller] --> A5 P3[Machine & App State Puller] --> A1 P3 --> A2 P3 --> A3 P4[Kea Hosts Puller] --> A6 A1([New Subnet 7]) --> B[Blaster] A2([Updated Network 2]) --> B[Blaster] A3([Removed App 1]) --> B[Blaster] A4([Updated Stats for Subnet 4]) --> B[Blaster] A5([Changed HA Status for Daemon 8]) --> B[Blaster] A6([New Host Reservation 3]) --> B[Blaster] B --> C[Alerts Rules Engine] C --> B B --> D[Event Log in DB<br/><br/>1. event x<br/>2. event y <A><br/>3. event z] B -->|SSE| E1[Web Browser 1] B -->|SSE| E2[Web Browser 2] B -->|SSE| E3[Web Browser 3] style B fill:#f9f style C fill:#fdf style D fill:#dff
Blaster collects events that are sent to it from various modules in Stork server. Then it checks in Alerts Rules Engine if given event qualifies to be an alert. Then the event is stored in database, in Event Log table. The next step is broadcasting the event to subscribers. Blaster checks criteria submitted by subscribers and sends the event to these with matching criteria. The event is sent to web browser using Server-sent Events (SSE).
Blaster is a goroutine that is collecting events via input channel.
Alerts Rules Engine
Alerts Rules Engine is a function that determines if given even should raise an alarm. It is based on rules defined by Stork administrator. A rule can be a global threshold for subnet pool utilization, etc.
Event Log in DB
Event Log is a table in database. It stores information about events. Each entry contains:
date of event
description of event in text form
reference(s) to related entities (foreign keys to other tables like e.g. Subnet)
The design of the table allows filtering entries by related entity or entity type. This allows presenting events in UI by entity type or by given entity.
Subscriber / Web Browser / UI
When user in web browser enters particular page in Stork Web UI, the code of this page should subscribe to events that this page is interested in. If this is e.g. machines page it should subscribe to events related to machines. IF this is a page of particular application it should subscribe to events connected with this application. If this is the main dashboard then it should subscribe to all events. Each page should read the events that are sent to them and update the UI accordingly.
Are the rules persistent, i.e. as an admin I log in, set a rule to get alert about X, then log out, X happens, after some time I log in. Will I see a notification?
I think we need to manage the event types somehow. There will be a lot of them very soon. A separate table with event types? It should be easily extensible, possibly by different independent devs.