Jump to: navigation, search

Difference between revisions of "Vitrage"

(High Level Architecture)
(High Level Architecture)
 
(100 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<gallery>
+
__NOTOC__
File:Vitrage logo finaly.png
 
</gallery>
 
  
 +
[[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]
  
 
== What is Vitrage? ==
 
== What is Vitrage? ==
Vitrage is the Openstack RCA (Root Cause Analysis) Engine for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing the existence of problems before they are directly detected.
+
Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.
 +
 
 +
=== High Level Functionality ===
 +
# Physical-to-Virtual entities mapping
 +
# Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)
 +
# Root Cause Analysis (RCA) for alarms/events
 +
# Horizon plugin for the above features
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
== High Level Architecture ==
 +
 
 +
[[File:Vitrage_architecture_train.png|2000px|frameless|center|Vitrage High Level Architecture]] <br />
  
== Mission & Scope ==
 
Vitrage is a project dedicated to making the events and alarms in OpenStack more meaningful and helpful. The ideal to which we strive is that every significant event in the system should have a timely alarm/event generated for it, that alarms are raised as early as possible after the event, and that the cause-effect relationships between different events is understood and visualized.
 
  
The Vitrage project is intended to be a part of Ceilometer project. It will get events and alarms from Aodh and from other OpenStack components. Whenever a new alarm is raised, it will process it and may produce RCA information, create alarm aggregation or raise new Alarms in Aodh.
+
'''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical & virtual, alarms, etc.. The information is then processed into the Vitrage Graph. Currently Vitrage comes ready with data sources for Nova, Cinder, and Aodh OpenStack projects, Nagios alarms, and a static Physical Resources data source.  
  
[[File:Vitrage.architecture.png|frameless|left|2000px|Vitrage - proposed architecture]] <br />
+
'''Vitrage Graph.''' Holds the information collected by the Data Sources, as well as their inter-relations. Additionally, it implements a collection of basic graph algorithms that are used by the Vitrage Evaluator (e.g., sub-matching, BFS, DFS etc).
  
== High Level Functionality ==
+
'''Vitrage Evaluator.''' Coordinates the analysis of (changes to) the Vitrage Graph and processes the results of this analysis. It is responsible for execution different kind of template-based actions in Vitrage, such as to add an RCA (Root Cause Analysis) relationship between alarms, raise a deduced alarm or set a deduced state.
# Root Cause Analysis (RCA) for alarms/events
+
 
# Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of system, not only direct monitoring)
+
For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]
# Alarm Aggregation (i.e., grouping alarms by categories, such as resources and severity, making them more manageable and understandable)
 
# Physical-to-Virtual entities mapping
 
# UI support for all features above
 
  
 
== Use Cases ==
 
== Use Cases ==
 
=== Baseline ===
 
=== Baseline ===
We consider the following example, where a we are monitoring a Switch (id 1002), for example via Nagios test, and as a result an alarm is raised on a Switch. The following image depicts the logical relationship among different resources in the system that are related to this switch. Note the mapping between virtual (machine) and physical (host, switch) entities.
+
[[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] <br />
 +
 
 +
We consider the following example, where a we are monitoring a Switch (id 1002), for example via Nagios, and as a problem on the Switch causes a Nagios alarm (a.k.a. Nagios test) to be activated. The following image depicts the logical relationship among different resources in the system that are related to this switch, as well as the raised alarm. Note the mapping between virtual (instance) and physical (host, switch) entities, as well as between the alarm and the switch it relates to.
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
  
[[File:Rca-baseline.jpg|2000px|frameless|center|Baseline]] <br />
 
  
  
 
=== Deduced alarms & states ===
 
=== Deduced alarms & states ===
The problems on the switch can, at times, have a bad impact on the VMs running on hosts attached to the switch, and we would like to have an alarm on those VMs to indicate this, as shown here:
+
[[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]]  <br />
 +
 
 +
Problems on the switch can, at times, have a negative impact on the virtual instances running on hosts attached to the switch. We would like to raise an alarm on those instances to indicate this impact, as shown here:
 +
 
 +
As can be seen, the problem on the switch should trigger an alarm on all instances associated with the switch. Similarly, we might want the state of all these instances to be changed to "ERROR" as well. This functionality should be supported even if we cannot directly monitor the state of the instances. Instances might not be monitored for all aspects of performance, or perhaps the problem in the switch makes monitoring them difficult or even impossible. Instead, we can '''deduce''' this problem exists on the instances based on the state of the switch, and raise alarms and change states accordingly.
  
[[File:DeducedAlarm.jpg|2000px|frameless|center|Deduced Alarm]]  <br />
 
  
As can be seen, an alarm is raised on all VMs associated with the switch. Similarly, we could want the state of all VMs to be changed to "ERROR". We would like to be able to do this even if, perhaps due to the problem with the switch, we cannot directly monitor the state of the VMs, since we can deduce this problem from the state of the switch.
 
  
=== Root Cause Indicators ===
 
Furthermore, we would like to be able to track this cause and effect - that the problem in the switch caused a problem in the VMs. In the following image, we highlight a single connection between the cause and effect for clarity - but all such links will be supported.
 
  
Important Note: not all deduced alarms are caused by the trigger - the trigger might only be an indication of correlation, not causation. In the case we are examining, however, the trigger is also the cause:
 
  
[[File:RootCauseExample.jpg|2000px|frameless|center|Root Cause Link]]  <br />
 
  
Once the local "causes" links (one hop) are detected and registered, we can follow them one hop after another to track the full causal chain of a sequence of events.
 
  
  
== Design & Implementation ==
 
=== High Level Architecture ===
 
  
[[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] <br />
 
  
  
'''Vitrage Virtual Synchronizer'''
 
  
Responsible for importing information regarding the virtual entities into Vitrage. Virtual entities can be, for example, virtual machines and virtual storage.
 
It collects this data from different sources, including (but not limited to) Openstack, and saves it in Vitrage Graph.
 
  
  
'''Vitrage Physical Synchronizer'''
 
  
Responsible for importing information regarding the physical entities into Vitrage. Phyical entities can be, for example, physical hosts and switches.
+
=== Root Cause Indicators ===
It collects this data from different sources, including (but not limited to) Openstack, and saves it in Vitrage Graph
+
[[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]]  <br />
  
 +
Furthermore, we would like to be able to track this cause and effect - that the problem in the switch caused the problems experienced at the instances. In the following image, we highlight a single connection between the cause and effect for clarity - but all such links should be supported.
  
'''Vitrage Alarm Synchronizer'''
+
Important Note: not all deduced alarms are ''caused'' by the trigger - the trigger might only be an indication of correlation, not causation. In the case we are examining, however, the trigger alarm is also the cause:
  
Responsible for importing alarms regarding entities in the cloud into Vitrage. It collects this data from different sources, including (but not limited to) Openstack, and saves them in Vitrage Graph.
+
Once the local "causes" links (one hop) are detected and registered, we can follow them one hop after another to track the full causal chain of a sequence of events.
  
  
'''Vitrage Graph'''
 
  
Representation of the different entities in the Cloud and their inter-relations. Relationships can range from the topological (e.g., which host a VM is hosted on) to the logical (e.g., one alert causes a different alert).  It contains the graph DB itself and a collection of basic graph algorithms (e.g., sub-matching algorithms , BFS, DFS and etc).
 
  
  
'''Vitrage Evaluator'''
 
  
Coordinates the analysis of the Vitrage Graph and processes the results of this analysis.
 
  
Responsible for execution of the following actions:
 
*RCA – Root Cause Analysis
 
*Deduce Alerts – Raise an alert as a result of other alert(s) or other events and changes in the Cloud
 
*Deduce state – Updating resource state as result of other alert(s) or other events and changes in the Cloud
 
  
  
'''Vitrage API'''
 
  
The API for Vitrage. Enables to receive information from the Vitrage Graph regarding the cloud and analysis related to root cause.
 
  
  
'''Vitrage Notifier'''
+
== Demos and Presentations ==
 +
=== Quick Demos (A bit outdated) ===
 +
* [https://www.youtube.com/watch?v=tl5AD5IdzMo&feature=youtu.be Vitrage Functionalities Overview]
 +
* [https://www.youtube.com/watch?v=GyTnMw8stXQ&feature=youtu.be Vitrage Get Topology Demo]
 +
* [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]
 +
* [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]
 +
 
 +
=== Summit Sessions ===
 +
==== OpenStack Austin, April 2016 ====
 +
* [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]
 +
* [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage & OPNFV Doctor collaboration]
 +
==== OPNFV Berlin, June 2016 ====
 +
* [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]
 +
* [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]
 +
==== OpenStack Barcelona, October 2016 ====
 +
* [https://www.openstack.org/videos/video/demo-openstack-and-opnfv-keeping-your-mobile-phone-calls-connected OpenStack Keynotes demo with Doctor - Keeping Your Mobile Phone Calls Connected]
 +
* [https://www.openstack.org/videos/video/nokia-root-cause-analysis-principles-and-practice-in-openstack-and-beyond Root Cause Analysis Principles and Practice in OpenStack and Beyond]
 +
* [https://www.openstack.org/videos/video/fault-management-with-openstack-congress-and-vitrage-based-on-opnfv-doctor-framework Fault Management with OpenStack Congress and Vitrage Based on OPNFV Doctor Framework]
 +
==== OpenStack Boston, May 2017 ====
 +
* [https://www.openstack.org/videos/boston-2017/beyond-automation-taking-vitrage-into-the-realm-of-machine-learning Beyond Automation - Taking Vitrage Into the Realm of Machine Learning]
 +
* [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]
 +
* [https://www.openstack.org/videos/boston-2017/the-vitrage-story-from-nothing-to-the-big-tent The Vitrage Story - From Nothing to the Big Tent]
 +
* [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]
 +
* [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]
 +
==== OpenStack Sydney, November 2017 ====
 +
* [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]
 +
* [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]
 +
==== OpenStack Vancouver, May 2018 ====
 +
* [https://www.openstack.org/videos/vancouver-2018/closing-the-loop-vnf-end-to-end-failure-detection-and-auto-healing Closing the Loop: VNF end-to-end Failure Detection and Auto Healing]
 +
* [https://www.openstack.org/videos/vancouver-2018/extend-horizon-headers-for-easy-monitoring-and-fault-detection-and-more Extend Horizon Headers for easy monitoring and fault detection - and more]
 +
* [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]
 +
* [https://www.openstack.org/videos/vancouver-2018/proactive-root-cause-analysis-with-vitrage-kubernetes-zabbix-and-prometheus Proactive Root Cause Analysis with Vitrage, Kubernetes, Zabbix and Prometheus]
  
Responsible to inform the different services with the Vitrage evaluator results.
 
  
 
== Development (Blueprints, Roadmap, Design...) ==
 
== Development (Blueprints, Roadmap, Design...) ==
* [https://blueprints.launchpad.net/vitrage Blueprints]
+
* [https://docs.openstack.org/vitrage/latest Vitrage Documentation]
* [https://github.com/openstack/vitrage Source Code]
+
* Vitrage in StoryBoard:
* Project at Launchpad: http://launchpad.net/vitrage
+
** [https://storyboard.openstack.org/#!/board/90 Main board]
* IRC channel for regular daily discussions: #openstack-vitrage
+
** [https://storyboard.openstack.org/#!/board/89 Bugs]
* [https://launchpad.net/~vitrage-drivers Vitrage Team]
+
** [https://etherpad.openstack.org/p/vitrage-storyboard-migration StoryBoard how-to]
 +
* [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]
 +
* Source code:
 +
** [https://github.com/openstack/vitrage vitrage]
 +
** [https://github.com/openstack/python-vitrageclient python-vitrageclient]
 +
** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]
 +
** [https://github.com/openstack/vitrage-tempest-plugin vitrage-tempest-plugin]
 +
 
 +
=== Design Discussions ===
 +
* [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]
 +
* [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]
 +
* [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]
 +
* [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]
 +
* [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]
 +
* [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]
 +
 
  
== Subpages ==
+
== Communication and Meetings ==
 +
=== Meetings ===
 +
* Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode
 +
* Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details
  
{{Special:PrefixIndex/:Vitrage/}}
+
=== Contact Us ===
 +
* IRC channel for regular daily discussions: #openstack-vitrage
 +
* Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-discuss/ OpenStack Mailing List]

Latest revision as of 11:08, 23 May 2019


OpenStack Project Vitrage horizontal.png

What is Vitrage?

Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms & events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.

High Level Functionality

  1. Physical-to-Virtual entities mapping
  2. Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)
  3. Root Cause Analysis (RCA) for alarms/events
  4. Horizon plugin for the above features




High Level Architecture

Vitrage High Level Architecture


Vitrage Data Source(s). Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical & virtual, alarms, etc.. The information is then processed into the Vitrage Graph. Currently Vitrage comes ready with data sources for Nova, Cinder, and Aodh OpenStack projects, Nagios alarms, and a static Physical Resources data source.

Vitrage Graph. Holds the information collected by the Data Sources, as well as their inter-relations. Additionally, it implements a collection of basic graph algorithms that are used by the Vitrage Evaluator (e.g., sub-matching, BFS, DFS etc).

Vitrage Evaluator. Coordinates the analysis of (changes to) the Vitrage Graph and processes the results of this analysis. It is responsible for execution different kind of template-based actions in Vitrage, such as to add an RCA (Root Cause Analysis) relationship between alarms, raise a deduced alarm or set a deduced state.

For more information, refer to the low level design

Use Cases

Baseline

Baseline

We consider the following example, where a we are monitoring a Switch (id 1002), for example via Nagios, and as a problem on the Switch causes a Nagios alarm (a.k.a. Nagios test) to be activated. The following image depicts the logical relationship among different resources in the system that are related to this switch, as well as the raised alarm. Note the mapping between virtual (instance) and physical (host, switch) entities, as well as between the alarm and the switch it relates to.









Deduced alarms & states

Deduced Alarm

Problems on the switch can, at times, have a negative impact on the virtual instances running on hosts attached to the switch. We would like to raise an alarm on those instances to indicate this impact, as shown here:

As can be seen, the problem on the switch should trigger an alarm on all instances associated with the switch. Similarly, we might want the state of all these instances to be changed to "ERROR" as well. This functionality should be supported even if we cannot directly monitor the state of the instances. Instances might not be monitored for all aspects of performance, or perhaps the problem in the switch makes monitoring them difficult or even impossible. Instead, we can deduce this problem exists on the instances based on the state of the switch, and raise alarms and change states accordingly.








Root Cause Indicators

Root Cause Link

Furthermore, we would like to be able to track this cause and effect - that the problem in the switch caused the problems experienced at the instances. In the following image, we highlight a single connection between the cause and effect for clarity - but all such links should be supported.

Important Note: not all deduced alarms are caused by the trigger - the trigger might only be an indication of correlation, not causation. In the case we are examining, however, the trigger alarm is also the cause:

Once the local "causes" links (one hop) are detected and registered, we can follow them one hop after another to track the full causal chain of a sequence of events.







Demos and Presentations

Quick Demos (A bit outdated)

Summit Sessions

OpenStack Austin, April 2016

OPNFV Berlin, June 2016

OpenStack Barcelona, October 2016

OpenStack Boston, May 2017

OpenStack Sydney, November 2017

OpenStack Vancouver, May 2018


Development (Blueprints, Roadmap, Design...)

Design Discussions


Communication and Meetings

Meetings

  • Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode
  • Check Vitrage Meetings for more details

Contact Us

  • IRC channel for regular daily discussions: #openstack-vitrage
  • Use [Vitrage] tag for Vitrage emails on OpenStack Mailing List