... | ... | @@ -83,4 +83,22 @@ When user in web browser enters particular page in Stork Web UI, the code of thi |
|
|
|
|
|
1. More descriptive name for EventsCenter
|
|
|
2. List currently envisioned events. Let's see if there are some obvious patterns.
|
|
|
3. Propose Event structure. |
|
|
\ No newline at end of file |
|
|
3. Propose Event structure.
|
|
|
|
|
|
# Comments about Scope and Requirements
|
|
|
Alarming has 3 components
|
|
|
1. the application notification that there is a fault or condition that needs attention (these can come from both Kea and Stork)
|
|
|
2. the management process that determines whether to raise or silence an alarm, severity, alarm channels, history, etc
|
|
|
3. the management of and communication with alerting channels, such as email, pagerduty, text, etc
|
|
|
|
|
|
We have already determined we are going to rely on an external application for #3, that is not something we want to integrate directly into Stork.
|
|
|
|
|
|
The more we look at #2, the more it seems to me that perhaps we should not build a full-featured capability in Stork either. Most organizations of any size have an established fault management application, like Nagios or Zabbix that is monitoring for alerts on all their critical applications. These can be pretty elaborate and it would be a pretty significant chunk of functionality to add to Stork. We should see how far we can go with a direct integration from Kea to these systems. We can satisfy most requirements by pointing to, e.g. Kea integration with Nagios. So, I am thinking maybe we want to build only a minimal management capability for alerts in Stork, with the expectation that Kea admins will primarily rely on some other dedicated fault management system for their alert channel.
|
|
|
|
|
|
So what Kea alerts should we display in Stork?
|
|
|
There will be some application conditions that only Stork knows about, so only Stork can raise an alarm. These include things that are Stork application events, like monitoring and un-monitoring servers, adding and removing Stork user accounts, etc. Events that arise from a combination of looking at Kea configuration data and use data, Pool utilization primarily, might be a special category of Kea alarm that is only available in Stork. If possible, it would be ideal if Stork could be configured to forward these to whatever 'standard' alerting system we integrate Kea with.
|
|
|
|
|
|
When an alarm is raised from Kea, say like a HA pair state change - that information could flow from Kea to both Stork and an alarm system (e.g. Nagios). Given the choice, a user who may have been alerted by Nagios is going to want to view the alarm in Stork because there is a better chance they can drill down to get more information in Stork (not yet, but eventually). So, we should reflect critical Kea events in Stork even if they are also in Nagios and if we can't provide a lot of fancy threshold-crossing and severity management features in Stork.
|
|
|
|
|
|
One way to show Kea events in Stork might be by creating logging channels in Kea that Stork 'subscribes' to. We could set Stork to show the highest severity log messages.
|
|
|
|