GitLab

• Information Types and Sources
• Data Pullers
• Blaster Design
  • Overview
  • Workflow
  • Blaster
  • Alerts Rules Engine
  • Event Log in DB
  • Subscriber / Web Browser / UI
  • Open questions
  • Problems to be resolved

Information Types and Sources

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.

Information	Changes Frequency	Refresh Rate
AgentVersion	low
Hostname	low
Cpus	low
Memory	low
Os	low
Platform	low
PlatformFamily	low
PlatformVersion	low
KernelVersion	low
KernelArch	low
VirtualizationSystem	low
VirtualizationRole	low
CpusLoad	high
UsedMemory	high
Uptime	medium
App.Active	low	high???
App.Address	low
App.Port	low
App.Version	low
Lease Stats	high
Host Reservations	high
Leases	high
App.HA.Config	low	low
App.HA.State	low	high
App.HA.LastFiloverEvent	low
App.Daemons.logs	high	???
LPS	high	???

Data Pullers

This is a list of data pullers implemented in Stork Server. Each one pulls some kind of data from Stork Agents.

Name	Interval
BIND 9 Stats Puller	60 sec
Kea Stats Puller	60 sec
Kea Hosts Puller	60 sec
Kea Status Puller	30 sec
Machine & App State Puller (new)	???

Blaster Design

Overview

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.

Workflow

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

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.

Open questions

1. 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?

2. 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.

3. Don't assume that SSE will be the only way to consume alerts. It will be for a while, but later down the road we may integrate with some existing notification systems, like prometheus' altermanager or stackexchange's bosun.

Problems to be resolved

1. More descriptive name for Blaster
2. List currently envisioned events. Let's see if there are some obvious patterns.
3. Propose Event structure.