...
Holmes is a root cause analytics application. It is targeted to find out the root cause among tons of alarms with the help of the topology information of resources provided by A&AI. Meanwhile, if needed, it could also correlate on one alarm with another if they are topologically related and fulfill the criteria which are set up in a sepcific specific rule.
Holmes is a an application managed by DCAE. The position of Holmes in ONAP is dipicted in the picture bellow.
...
As for the architecture of Holmes itself, it comprises two sub-modules: the a rule management module and the an engine management module.
...
The engine management module is where all rules run. For now, there's a data source adapter (aka DSA) which is responsible for converting the VES event into the format that Holmes could deal with residing in this module.
New component capabilities for Dublin, i.e. the functional enhancements.
...
- api/holmes-rule-mgmt/v1/rule
- api/holmes-engine-mgmt/v1/rule
In addition, we use method methods PUT/POST/DELETE/GET to distinguish different behaviors for the APIs that share the same name.
...
- Scalability of the engine management module is feasible but not perfect. Holmes dispatches all of the active rules into different instances evenly. This could reduce the payload of each engine a little bit, but not much.
- It could be a bottleneck bottle neck when it comes to the performance on the interactions with A&AI during alarm analysis. This is now on the discussion list of the A&AI team and we are trying to figure out a way to optimize it.
...