Brief Project Overview (brief as it should be known)
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 one alarm with another if they are topologically related and fulfill the criteria which are set in a sepcific rule.
Holmes is 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: a rule management module and an engine management module.
The rule management module is the entry for all Holmes rules. It interacts with other components (i.g. DCAE) to get rules, save them into the DB and then deploy the active rules into the 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.
- Integration with AAF to implement authorization and authentication.
New or modified interfaces
There's no interface change in R4. Besides, Holmes is basically a consumer rather than a provider of APIs. In other words, all defined APIs for Holmes are intended for internal use. The interactions between Holmes and other ONAP components are implemented through DMaaP.
For reference, all Holmes APIs are defined here.
Interface naming
The pattern of API names of Holmes is like <protocol>://<host>:<port>/api/<module-name>/<version>/<func> .
For example, for health check, the APIs are like:
- api/holmes-rule-mgmt/v1/healthcheck
- api/holmes-engine-mgmt/v1/healthcheck
For rule related operations, the APIs are like:
- api/holmes-rule-mgmt/v1/rule
- api/holmes-engine-mgmt/v1/rule
In addition, we use methods PUT/POST/DELETE/GET to distinguish different behaviors for the APIs that share the same name.
Reference to the interfaces.
Holmes APIs for R4 are defined here.
What are the system limits?
- 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 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.
Involved use cases, architectural capabilities or functional requirements.
- VoLTE
- CCVPN
Listing of new or impacted models used by the project (for information only).
- None.