Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Programmable Northbounder Interfaces

Description

On several customer deployments, I’ve seen lots of customizations through Scripts or Drools that expect alarms instead of events. The problem is that the current daemons are triggered by events, which makes the workflow harder if you are interested on alarms, as it might be a slight delay when an alarm is created and associated with an existing event.

For this reason the Northbounder interface was created. Unfortunately there is no way to execute custom code or perform business logic when an alarm is created. The idea is implement a Drools NBI, and Script NBI so we can trigger custom logic associated with NorthboundAlarm instead of Event.

The usage would be very similar to the current ones. One difference is that the Drools NBI won’t implement timers as this is a bad practice. If someone needs time based rules then Drools Fusion (or CEP) should be used on the rules. That facilitates the reload operation, assuming the working memory can be restored, which depends on the changes performed on the rules.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Alejandro Galue July 25, 2017 at 8:19 PM

Alejandro Galue July 25, 2017 at 1:36 PM
Edited

There was a request for merging the configuration of the Drools NBI with the Drools Correlator. Initially, it looks like a good idea but here is why I do not recommend to do it:

1) It would be confusing that all the NBIs have similar configuration files, and now have one that won't follow the same principles. Some of those principles are:

    1.1) Be able to enable/disable an NBI implementation on demand (i.e. while OpenNMS is up and running). This is not possible because the Event Correlator doesn't have a single configuration file. Instead, it has independent configuration files per engine, so we will still need to have a configuration file somewhere to provide this feature.

    1.2) Enable engines based on a SPEL expression against a NorthboundAlarm besides UEIs, which is an object irrelevant for the event correlator. Drools and even BeanShell can be expensive, compared with SPEL, so having a second level filtering would minimize CPU cycles on this regard, and this is a feature the Event Correlator doesn't have.

2) Force undesired features on the Drools NBI, like optionally enable/disable the state persistence. This feature is optional on the Event Correlator for backward compatibility purposes (as in my opinion, it should always be enabled).

3) There are business logic inside the classes that handle the Event Correlator that is irrelevant for the NBI (like create the DroolsCorrelationEngine itself). That means, a major refactoring is required in order to avoid make the Drools NBI depends on the Drools Correlator implementation.

Alejandro Galue July 18, 2017 at 1:20 PM

There is a branch on JIRA with the current initial work (verified on a test environment).

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created July 17, 2017 at 10:51 PM
Updated September 20, 2017 at 3:32 PM
Resolved August 28, 2017 at 2:15 PM