... | @@ -44,13 +44,14 @@ Information to be refreshed: |
... | @@ -44,13 +44,14 @@ Information to be refreshed: |
|
|Kea Status Puller | 30 sec |
|
|
|Kea Status Puller | 30 sec |
|
|
|
|
|
|
## Blaster Design
|
|
## Blaster Design
|
|
|
|
### Overview
|
|
`Blaster` is a module of Stork server that is responsible for collecting `events` and dispatching them to `subscribers`.
|
|
`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.
|
|
`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.
|
|
`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.
|
|
|
|
|
|
|
|
### Workflow
|
|
```mermaid
|
|
```mermaid
|
|
graph LR
|
|
graph LR
|
|
A1([New Subnet 1]) --> B[Blaster]
|
|
A1([New Subnet 1]) --> B[Blaster]
|
... | @@ -71,4 +72,25 @@ graph LR |
... | @@ -71,4 +72,25 @@ graph LR |
|
|
|
|
|
```
|
|
```
|
|
|
|
|
|
`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. 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)](https://en.wikipedia.org/wiki/Server-sent_events). |
|
`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)](https://en.wikipedia.org/wiki/Server-sent_events).
|
|
|
|
|
|
|
|
### Blaster
|
|
|
|
|
|
|
|
`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. |
|
|
|
\ No newline at end of file |