Project Name:
...
- Holmes project provides alarm correlation and analysis for Telecom cloud infrastructure and services, including hosts, vims, VNFs and NSs. Holmes aims to find the real reason which causes the failure or degradation of services by digging into the ocean of events collected from different levels of the Telecom cloud.
- Holmes provides docker(s) based fault correlation analysis system with APIs which could be called by external systems.
As as stretch goal, DCAE supports Holmes to be deployed as an analytic application in the form of docker(s). Actual deployment options are flexible, which should be decided by the user/use cases, Holmes can be either deployed as a standalone alarm correlation application or be integrated into DCAE as an analytic application.
| Info | ||
|---|---|---|
| ||
Both Holmes and Policy adopt Drools as the rules engine. The main difference between these two projects is that Holmes is mainly targeted at correlation analysis between different alarms while Policy is aimed to implement control loops by triggering a series of actions. Briefly speaking, Holmes is targeted at root cause analysis but policy is aimed for auto-healing/auto-scaling.
Policy does not need to face the original alarms directly with the help of Holmes. The root cause is picked out from all the original alarms by Holmes and then, the most suitable policy ID is selected and published accordingly. In this way, Policy is liberated from triggering similar or duplicated actions which are caused by the alarms with internal relations. For example, if there are 3 events A, B and C which could lead to a power down fault, and B and C are caused by A. Without Holmes, all of these 3 events will be sent to Policy and 3 corresponding actions are going to be triggered. After we add Holmes to the close loop controller and make it the upstream system of Policy, only Event A will be sent to Policy and thus only one action will be triggered, which makes the close loop control more precise and efficient. A Scenario without Holmes
A Scenario with Holmes
|
...
Holmes is an application that processes events published by managed resources or other applications that detect specific conditions. Based on defined root cause analysis rules about the network, an application of this kind would determine root cause for various conditions and notify other interested applications.
Holmes is designed in compliance with the VES standard. It can take event data from DMaaP, consume them and then send the correlation result back to DMaaP in the form of VES structure. Any other projects subscribe to the corresponding topic could fetch and use the result.
Holmes consists of a rule designer and a correlation engine.
Real-time Analytic application get the analysis result, which is the root cause can be used to drive the policy run-time for automation operation.
Correlation Engine receives original alarms from monitor and outputs the result back to monitor after analysis based on rules and the resources relationships from A&AI.
The Rule Designer provides a user-friendly GUI to design the Correlation rules. The GUI can be either run in standalone mode or integrated into other projects if needed.
Stretch Goal
...
.
Resources:
| Role | Name | Gerrit ID | Company | Email | TimeZone |
|---|---|---|---|---|---|
| Primary Contact | Guangrong Fu | ZTE | Beijing, China. UTC +8 | ||
| Commiters | Guangrong Fu | ||||
| Peng Tang | ZTE | tang.peng45@zte.com.cn | Beijing, China. UTC +8 | ||
| Contributors | Jiaqiang Du | ZTE | du.jiaqiang@zte.com.cn | Beijing, China. UTC +8 | |
| Yi Li | ZTE | li.yi101@zte.com.cn | Beijing, China. UTC +8 | ||
| Youbo Wu | ZTE | Beijing, China. UTC +8 | |||
| Liang Feng | ZTE | feng.liang1@zte.com.cn | Beijing, China. UTC +8 | ||
| Yuan Liu | China Mobile | liuyuanyjy@chinamobile.com | Beijing, China. UTC +8 | ||
| Chengli Wang | China Moblile | wangchengli@chinamobile.com | Beijing, China. UTC +8 | ||
| Xin(Saw) Jin | Huawei | saw.jin@huawei.com | Beijing, China. UTC +8 |
...