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 on alarm with another if they are topologically related and fulfill the criteria which are set up in a sepcific rule.
Holmes is a application managed by DCAE. The position of Holmes is dipicted in the picture bellow.
As for the architecture of Holmes itself, it comprises two sub-modules: the rule management module and the 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.
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 method 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, but not much.
- It could be a bottleneck when it comes to 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.