... | ... | @@ -81,7 +81,7 @@ When user in web browser enters particular page in Stork Web UI, the code of thi |
|
|
|
|
|
# Problems to be resolved
|
|
|
|
|
|
1. More descriptive name for EventsCenter
|
|
|
1. More descriptive name for EventsCenter
|
|
|
2. List currently envisioned events. Let's see if there are some obvious patterns.
|
|
|
3. Propose Event structure.
|
|
|
|
... | ... | @@ -91,7 +91,7 @@ Alarming has 3 components |
|
|
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.
|
|
|
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.
|
|
|
|
... | ... | @@ -101,4 +101,3 @@ There will be some application conditions that only Stork knows about, so only S |
|
|
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. |
|
|
|