Page Comparison

DRAFT

Current Overall Architecture

Image Modified
In ONAP, Holmes is deployed as an analytics application of DCAE. So basically, Holmes is spun up and configured through DCAE. During the runtime, Holmes has to interact with the following components:

• CLAMP - CLAMP is the place in which the correlation rules are designed. Ideally, all the Holmes rules are designed in CLAMP cockpit and then deployed into DCAE. 
• MSB - MSB is a mandatory dependency of Holmes. All HTTP requests are transferred by MSB from Holmes to other components, such as communications with DMaaP and AAI. Even inside Holmes, the sub-modules call each other's API via MSB.
• AAI - Holmes uses the resource information provided by AAI as a clue for alarm correlation. Only alarms with topologically correlated resources are considered to have some kind of relationship with each other.
• DMaaP - DMaaP is the message bus Holmes mainly depends on. Without DMaaP, Holmes, for now, is now able to get or publish any message. In the past two release, Holmes subscribes to "unauthenticated.SEC_FAULT_OUTPUT" to get VES events as its input. Meanwhile, it publishes its analytic results to the "unauthenticated.DCAE_CL_OUTPUT" for other components to consume.
• DCAE-PG - Holmes needs a database to store its rules and alarms. DCAE happens to have a PostgreSQL, hence Holmes uses the PG service provided by DCAE.
• DCAE-CBS - When Holmes is deployed as a DCAE application, all its configurations come from the DCAE configuration binding service, such as MSB information, Homles' external IP addresses and Holmes rules (for now), etc.

Planned Internal Architecture of Holmes

Ideally, Holmes comprises three kinds of functional modules: rule management, engine management and data source adapter.  For the actual internal architecture, please refer to the corresponding doc under the release folders (from Casablanca on).

Rule Management Module

The rule management module mainly works as a broker between the rule designer(DCAE-CBS) and the engine management module. This module is responsible for interactions with external systems for rule deployment. All rules get into Holmes and then are stored into the database and deployed into the Drools engine if the status of the rules is enabled. When it comes to the horizontal scaling scenario, this module is responsible for re-distribution of existing rules.

The rule management module itself is a stateless container. So it could be horizontally scaled by DCAE.

Engine Management Module

The engine management module is the core module of Holmes. Apache Drools is used as the reasoning engine of Holmes. All enabled rules are distributed into Drools engine and then Drools takes over all the work and output the correlation results.

Drools provides only a running environment for all rules. The actual correlation job is done by rules. Rules are script-based. They are not hard-coded into the code base. Instead, they are designed and written according to specific requirements for different scenarios. Rules could be composed and deployed using the rule designer of Holmes.

The engine management is stateful. It has to deal with existing rules and alarms when it comes to scaling. Holmes uses PG to persist its running data so that it could recover the statuses of different instances of the Holmes engine. Besides, data source adapters should be used along with engines to implement alarm balancing and distribution.

Data Source Adapter

Data source adapters are used to convert different event formats into a Holmes consumable one and vice versa.