https://wiki.openstack.org/w/api.php?action=feedcontributions&feedformat=atom&user=Ifat+Afek 2026-06-30T20:17:52Z User contributions MediaWiki 1.28.2 https://wiki.openstack.org/w/index.php?title=File:Vitrage_architecture_train.png&diff=170238 2019-05-23T11:16:37Z

<p>Ifat Afek: </p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Forum/Denver2019&diff=169748 2019-04-30T02:03:34Z

<p>Ifat Afek: </p> <hr /> <div>== Etherpads ==<br /> The grand list of all of the Denver 2019 [[Forum]] etherpads. Please add links to etherpads below!<br /> (You might use the prior Forum entries for ideas: https://wiki.openstack.org/wiki/Forum/Berlin2018 )<br /> <br /> At the Forum the entire OpenStack community (users and developers) gathers to brainstorm the requirements for the next release, gather feedback on the past version and have strategic discussions that go beyond just one release cycle. The Berlin Forum was the start of the planning phase for the '''T''' development cycle. Please prepare session ideas with feedback from the '''Stein''' release in mind.<br /> <br /> === Monday April 29 ===<br /> [11:10-11:50] [https://etherpad.openstack.org/p/DEN-keystone-forum-sessions-app-creds Keystone Application Credentials: Status and Planning]<br /> <br /> [11:10-11:50] [https://etherpad.openstack.org/p/DEN-train-next-steps-for-standalone-ironic Next steps for standalone ironic]<br /> <br /> [12:00-12:40] [https://etherpad.openstack.org/p/DEN-keystone-forum-sessions-operator-feedback Keystone Operator Feedback]<br /> <br /> [12:00-12:40] [https://etherpad.openstack.org/p/DEN-bare-metal-SIG Bare Metal SIG]<br /> <br /> [14:00-14:40] [https://etherpad.openstack.org/p/keystone-for-multi-tenancy-in-kubernetes Leveraging OpenStack Keystone for Multi-Tenancy Support in Kubernetes]<br /> <br /> [14:50-15-30] [https://etherpad.openstack.org/p/service-consumption Consumption models for service projects]<br /> <br /> [14:50-15-30] [https://etherpad.openstack.org/p/DEN-auto-scaling-SIG Auto-scaling SIG]<br /> <br /> [15:50-16:30] [https://etherpad.openstack.org/p/storyboard-pain-points Ibuprofen for Your StoryBoard Pain Points]<br /> <br /> [15:50-16:30] [https://etherpad.openstack.org/p/DEN-change-ownership-of-resources OpenStack: Change ownership of resources - followup]<br /> <br /> [14:40-15:20] [https://etherpad.openstack.org/p/DEN-Ops-Catch-Up Ops Community Gathering and Meetup Planning]<br /> <br /> [16:40-17:20] [https://etherpad.openstack.org/p/forum-technical-vision-doc Technical vision document: Check in and question session]<br /> <br /> === Tuesday April 30 ===<br /> [9:00-9:40] [https://etherpad.openstack.org/p/DEN-vitrage-use-cases-forum Use cases for the new vitrage RCA UI]<br /> <br /> [9:50-10:30] [https://etherpad.openstack.org/p/DEN-deployment-tools-capabilities Deployment tools: define common capabilities]<br /> <br /> [10:50-11:30] [https://etherpad.openstack.org/p/DEN-ECG-MVP-feedback Edge Computing Group MVP Architecture feedback]<br /> <br /> [11:40-12:20] [https://etherpad.openstack.org/p/DEN-ECG-use-cases-discssion-feedback Edge Computing use cases discussion and feedback]<br /> <br /> [13:40-14:20] [https://etherpad.openstack.org/p/DEN-update-on-placement-extraction-from-nova Update on placement extraction from nova]<br /> <br /> [14:30-15:10] [https://etherpad.openstack.org/p/DEN-ECG-roadmap-and-feedback What is the Edge Computing Group and what it should be doing in the next 6 months?]<br /> <br /> [14:30-15:10] [https://etherpad.openstack.org/p/DEN-ptl-tips-and-tricks PTL Tips and Tricks]<br /> <br /> [16:20-17:00] [https://etherpad.openstack.org/p/new-contribs-state-and-deduplication Welcoming New Contributors State of the Union and Deduplication of Efforts] <br /> <br /> [1710-1750] [https://etherpad.openstack.org/p/DEN-ops-war-stories-LT Ops War Stories/Architecture Show and Tell Lightning Talks]<br /> <br /> === Wednesday May 1 ===<br /> [09:00-09:40] [https://etherpad.openstack.org/p/DEN-qa-onboarding QA Onboarding]<br /> <br /> [09:00-09:40] [https://etherpad.openstack.org/p/DEN-openlab-whats-next OpenLab: We Integrated K8s, What is Next?]<br /> <br /> [10:50-11:30] [https://etherpad.openstack.org/p/Den-forum-qa-ops-user-feedback Users/Operators adoption of QA tools/plugins]<br /> <br /> [1340-1240] [https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps Closing compute API feature gaps in the openstack CLI]<br /> <br /> [13:40-14:20] [https://etherpad.openstack.org/p/denver-forum-cinder-improving-drvr-cap-rep Improving Cinder Driver Capability Reporting]<br /> <br /> [14:30-15:10] [https://etherpad.openstack.org/p/denver-forum-cinder-direct-user-feedback Cinder Opportunity for Direct User Feedback]<br /> <br /> [2:50-3:30] [https://etherpad.openstack.org/p/consumption-models Consumption Models for Service Projects]<br /> <br /> [3:20-4:00] [https://etherpad.openstack.org/p/DEN-tripleo-forum-scale TripleO architecture for thousand node scale ]<br /> <br /> [15:20-16:00] [https://etherpad.openstack.org/p/DEN-Deletion-of-resources OpenStack: Project Resource Cleanup - followup]<br /> <br /> [4:20-5:00] [https://etherpad.openstack.org/p/DEN-drive-common-goals OpenStack: how to drive common goals]<br /> <br /> [17:10-17:50] [https://etherpad.openstack.org/p/DEN-Operator-end-user-Public-cloud-feedback OpenStack: Operator, end user and Public cloud feedback]<br /> <br /> ==List of Brainstorming Etherpads==<br /> <br /> ===Catch-alls===<br /> If you want to post an idea, but aren't working with a specific team or working group, you can use these:<br /> * [https://etherpad.openstack.org/p/DEN-Train-TC-brainstorming Technical Committee Catch-all]<br /> * [https://etherpad.openstack.org/p/DEN-Train-UC-brainstorming User Committee Catch-all]<br /> <br /> ===Etherpads from Teams and Working Groups===<br /> * [https://etherpad.openstack.org/p/DEN-auto-scaling-SIG Auto scaling SIG]<br /> * [https://etherpad.openstack.org/p/DEN-Train-EWG-brainstorming Enterprise Working Group (EWG)]<br /> * [https://etherpad.openstack.org/p/Denver-2019-Forum-DCN-Brainstorming DCN]<br /> * [https://etherpad.openstack.org/p/DEN-fenix-forum-brainstorming Fenix]<br /> * [https://etherpad.openstack.org/p/FC_SIG_Denver_forum_topics First Contact SIG]<br /> * [https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming Ironic]<br /> * [https://etherpad.openstack.org/p/kayobe-train-forum Kayobe]<br /> * [https://etherpad.openstack.org/p/DEN-keystone-forum-sessions Keystone]<br /> * [https://etherpad.openstack.org/p/DEN-train-forum-manila-brainstorming Manila]<br /> * [https://etherpad.openstack.org/p/DEN-train-nova-brainstorming Nova]<br /> * [https://etherpad.openstack.org/p/edge-wg-forum-preparation-denver-2019 OSF Edge Computing Group]<br /> * [https://etherpad.openstack.org/p/oslo-train-topics Oslo]<br /> * [https://etherpad.openstack.org/p/DEN-Train-PublicCloudWG-brainstorming Public Cloud WG]<br /> * [https://etherpad.openstack.org/p/DEN-train-forum-qa-brainstorming QA]<br /> * [https://etherpad.openstack.org/p/DEN-self-healing-SIG Self healing SIG]<br /> * [https://etherpad.openstack.org/p/SB_train_forum_brainstorming StoryBoard]<br /> * [https://etherpad.openstack.org/p/DEN-Train-TC-brainstorming Technical Committee]<br /> * [https://etherpad.openstack.org/p/tripleo-train-topics TripleO]<br /> <br /> ===Etherpads from Pilot projects===<br /> * [https://etherpad.openstack.org/p/stx-forum-preparation-denver-2019 StarlingX]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=PTG/Train/Etherpads&diff=169510 2019-04-17T07:46:23Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> This is the list of etherpads for the Projects Team Gathering for the Train release in Denver, 2019. Each team can organize the content on their allocated day(s) in the way that seems to most appropriate to them. We suspect most teams will avoid strict timeboxed slots and will use etherpads to list topics to cover. This page lists those etherpads for easy reference.<br /> <br /> For more details on the event, see the [https://www.openstack.org/ptg/ event website].<br /> <br /> For what's happening '''right now''' (during the event), see the [http://ptg.openstack.org/ptg.html ptgbot page].<br /> <br /> === Projects ===<br /> * Charms - https://etherpad.openstack.org/p/charms-train-ptg<br /> * Cinder - https://etherpad.openstack.org/p/cinder-train-ptg-planning<br /> * Cyborg - https://etherpad.openstack.org/p/cyborg-ptg-train<br /> * Fenix - https://etherpad.openstack.org/p/DEN2019-fenix-PTG<br /> * Fenix - ETSI NFV - https://etherpad.openstack.org/p/DEN2019-fenix-NFV-FEAT03-PTG<br /> * Glance - https://etherpad.openstack.org/p/Glance-Train-PTG-planning<br /> * Heat - https://etherpad.openstack.org/p/DEN-Train-Heat<br /> * Horizon - https://etherpad.openstack.org/p/horizon-train-ptg<br /> * Ironic - https://etherpad.openstack.org/p/DEN-train-ironic-ptg<br /> * Keystone - https://etherpad.openstack.org/p/keystone-train-ptg<br /> * Magnum - https://etherpad.openstack.org/p/magnum-train-ptg<br /> * Manila<br /> ** Planning: https://etherpad.openstack.org/p/manila-denver-train-ptg-planning<br /> ** Minutes/Proceedings: https://etherpad.openstack.org/p/manila-ptg-train<br /> * Monasca - https://etherpad.openstack.org/p/monasca-ptg-train<br /> * Neutron - https://etherpad.openstack.org/p/openstack-networking-train-ptg<br /> * Nova - https://etherpad.openstack.org/p/nova-ptg-train<br /> * Octavia - https://etherpad.openstack.org/p/octavia-train-ptg<br /> * OpenStackAnsible - https://etherpad.openstack.org/p/osa-train-ptg<br /> * Oslo - https://etherpad.openstack.org/p/oslo-train-topics<br /> * Placement - https://etherpad.openstack.org/p/placement-ptg-train<br /> * QA/Tempest - https://etherpad.openstack.org/p/qa-train-ptg<br /> * Release Team - https://etherpad.openstack.org/p/relmgmt-train-ptg<br /> * Swift - https://etherpad.openstack.org/p/swift-ptg-train<br /> * Tripleo <br /> ** Schedule: https://etherpad.openstack.org/p/tripleo-ptg-train<br /> ** Topic Planning: https://etherpad.openstack.org/p/tripleo-train-topics<br /> * Vitrage - https://etherpad.openstack.org/p/vitrage-train-ptg<br /> <br /> === Cross-Project ===<br /> * Nova/Cinder - https://etherpad.openstack.org/p/ptg-train-xproj-nova-cinder<br /> * Nova/Cyborg - https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg<br /> * Nova/Ironic - https://etherpad.openstack.org/p/ptg-train-xproj-nova-ironic<br /> * Nova/Neutron - https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron<br /> * Nova/Placement - https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement<br /> <br /> === SIG/Theme/Other ===<br /> * API SIG - https://etherpad.openstack.org/p/api-sig-ptg-train<br /> * Technical Committee - https://etherpad.openstack.org/p/tc-train-ptg<br /> * Self-healing SIG - https://etherpad.openstack.org/p/DEN-self-healing-SIG<br /> * Security SIG - https://etherpad.openstack.org/p/security-sig-ptg-train<br /> <br /> === Pilot Projects ===<br /> <br /> <br /> === Other ===</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=167068 2018-12-04T11:18:27Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_rocky.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin, April 2016 ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin, June 2016 ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona, October 2016 ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston, May 2017 ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney, November 2017 ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver, May 2018 ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * [https://docs.openstack.org/vitrage/latest Vitrage Documentation]<br /> * Vitrage in StoryBoard:<br /> ** [https://storyboard.openstack.org/#!/board/90 Main board]<br /> ** [https://storyboard.openstack.org/#!/board/89 Bugs]<br /> ** [https://etherpad.openstack.org/p/vitrage-storyboard-migration StoryBoard how-to]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> ** [https://github.com/openstack/vitrage-tempest-plugin vitrage-tempest-plugin]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-discuss/ OpenStack Mailing List]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=File:Vitrage_architecture_rocky.png&diff=165982 2018-10-16T10:00:47Z

<p>Ifat Afek: Ifat Afek uploaded a new version of File:Vitrage architecture rocky.png</p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=File:Vitrage_architecture_rocky.png&diff=165149 2018-09-25T08:43:12Z

<p>Ifat Afek: </p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=165148 2018-09-25T08:42:39Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_rocky.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin, April 2016 ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin, June 2016 ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona, October 2016 ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston, May 2017 ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney, November 2017 ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver, May 2018 ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * [https://docs.openstack.org/vitrage/latest Vitrage Documentation]<br /> * Vitrage in StoryBoard:<br /> ** [https://storyboard.openstack.org/#!/board/90 Main board]<br /> ** [https://storyboard.openstack.org/#!/board/89 Bugs]<br /> ** [https://etherpad.openstack.org/p/vitrage-storyboard-migration StoryBoard how-to]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> ** [https://github.com/openstack/vitrage-tempest-plugin vitrage-tempest-plugin]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=162379 2018-06-28T11:51:51Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin, April 2016 ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin, June 2016 ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona, October 2016 ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston, May 2017 ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney, November 2017 ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver, May 2018 ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * [https://docs.openstack.org/vitrage/latest Vitrage Documentation]<br /> * Vitrage in StoryBoard:<br /> ** [https://storyboard.openstack.org/#!/board/90 Main board]<br /> ** [https://storyboard.openstack.org/#!/board/89 Bugs]<br /> ** [https://etherpad.openstack.org/p/vitrage-storyboard-migration StoryBoard how-to]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> ** [https://github.com/openstack/vitrage-tempest-plugin vitrage-tempest-plugin]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=162378 2018-06-28T11:45:25Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * [https://docs.openstack.org/vitrage/latest Vitrage Documentation]<br /> * Vitrage in StoryBoard:<br /> ** [https://storyboard.openstack.org/#!/board/90 Main board]<br /> ** [https://storyboard.openstack.org/#!/board/89 Bugs]<br /> ** [https://etherpad.openstack.org/p/vitrage-storyboard-migration StoryBoard how-to]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> ** [https://github.com/openstack/vitrage-tempest-plugin vitrage-tempest-plugin]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=162377 2018-06-28T11:33:44Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=162299 2018-06-25T10:44:33Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]<br /> ** [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]<br /> ** [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=162298 2018-06-25T10:44:06Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens PTG]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> ** [https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases Vancouver forum: Vitrage advanced use cases]<br /> ** [https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s Vancouver forum: Vitrage RCA over Kubernetes]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=162295 2018-06-25T10:36:23Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike Virtual PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens Virtual PTG]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=162293 2018-06-25T10:32:38Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> ==== OpenStack Vancouver ====<br /> * [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]<br /> * [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]<br /> * [https://www.openstack.org/videos/vancouver-2018/vitrage-project-update Vitrage - Project Update]<br /> * []<br /> * []<br /> * []<br /> * []<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike Virtual PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens Virtual PTG]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=First_Contact_SIG&diff=161946 2018-06-14T13:36:22Z

<p>Ifat Afek: </p> <hr /> <div>==First Contact SIG==<br /> <br /> '''Our Mission'''<br /> <br /> To provide a place for new contributors to come for information and advice. This group will also analyze and document successful contribution models while seeking out and providing information to new members of the community.<br /> <br /> '''Chairs'''<br /> * Kendall Nelson (diablo_rojo) UTC -8<br /> <br /> '''Members'''<br /> * Zhipeng Huang (zhipeng) UTC+8<br /> * Amy Marrich (spotz) UTC-6<br /> * Colleen Murphy (cmurphy) UTC+1<br /> * Ildikó Váncsa (ildikov) UTC+1 (UTC+2 with daylight saving)<br /> * Jay Bryant (jungleboyj) UTC-6<br /> * Ghanshyam Mann (gmann) UTC+9<br /> * Matt Oliver (mattolverau) UTC+10 (UTC+11 with daylight saving)<br /> * Gergely Csatari (csatari) UTC+1 (UTC+2 with daylight saving)<br /> * Surya Prakash Singh (spsurya) UTC+9<br /> <br /> ===Helpful Resources===<br /> * [https://www.openstack.org/community/ Contributor Portal] <br /> * [[Mentoring]] <br /> * [[Outreachy]]<br /> <br /> ===Project Liaisons===<br /> {| class=&quot;wikitable sortable&quot;<br /> ! Name<br /> ! IRC<br /> ! Email<br /> ! Timezone<br /> ! Project<br /> |-<br /> | Jay Bryant<br /> | jungleboyj<br /> | jungleboyj@gmail.com<br /> | UTC-6<br /> | [[Cinder|Cinder]]<br /> |-<br /> | Ivan Kolodyazhny<br /> | e0ne<br /> | e0ne@e0ne.info<br /> | UTC+3<br /> | [[Cinder|Cinder]]<br /> |-<br /> | Ivan Kolodyazhny<br /> | e0ne<br /> | e0ne@e0ne.info<br /> | UTC+3<br /> | [[Horizon|Horizon]]<br /> |-<br /> | Howard Huang<br /> | zhipeng<br /> | zhipengh512@gmail.com<br /> | UTC+8<br /> | [[Cyborg/FirstContact|Cyborg]]<br /> |-<br /> | Rico Lin<br /> | ricolin<br /> | rico.lin.guanyu@gmail.com<br /> | UTC+8<br /> | [[Heat|Heat]]<br /> |-<br /> | Frank Kloeker<br /> | eumel8<br /> | f.kloeker@telekom.de<br /> | UTC+1<br /> | I18n<br /> |-<br /> | Colleen Murphy<br /> | cmurphy<br /> | colleen@gazlene.net<br /> | UTC+1<br /> | Keystone<br /> |-<br /> | Cristiano Bellucci<br /> | cbellucci<br /> | Cristiano.bellucci@est.fujitsu.com<br /> | UTC+1<br /> | Monasca<br /> |-<br /> | Miguel Lavalle<br /> | mlavalle<br /> | miguel.lavalle@huawei.com<br /> | UTC-6<br /> | [[Neutron|Neutron]]<br /> |-<br /> | Slawek Kaplonski<br /> | slaweq<br /> | slawek@kaplonski.pl<br /> | UTC+1<br /> | [[Neutron|Neutron]]<br /> |-<br /> | Michael Johnson<br /> | johnsom<br /> | johnsomor@gmail.com<br /> | UTC-8<br /> | Octavia<br /> |-<br /> | Jean-Philippe Evrard<br /> | evrardjp<br /> | jean-philippe@evrard.me<br /> | UTC+2<br /> | OpenStack-Ansible<br /> |-<br /> | Chason Chan (chenxing)<br /> | chason<br /> | chason.chan@foxmail.com<br /> | UTC+8<br /> | OpenStack-Manuals<br /> |-<br /> | Ghanshyam Mann<br /> | gmann<br /> | gmann@ghanshyammann.com<br /> | UTC+9<br /> | [[QA|QA]]<br /> |-<br /> | Qiming Teng<br /> | Qiming<br /> | tengqim@cn.ibm.com<br /> | UTC+8<br /> | [[Senlin|Senlin]]<br /> |-<br /> | Matt Oliver<br /> | mattolverau<br /> | matt@oliver.net.au<br /> | UTC+10<br /> | Swift<br /> |-<br /> | Alexander Chadin<br /> | alexchadin<br /> | a.chadin@servionica.ru<br /> | UTC+3<br /> | Watcher<br /> |-<br /> | Hongbin Lu<br /> | hongbin<br /> | hongbin.lu@huawei.com<br /> | UTC-5<br /> | Zun<br /> |-<br /> | Victoria Martinez de la Cruz<br /> | vkmc<br /> | victoria@redhat.com<br /> | UTC-3<br /> | Manila<br /> |-<br /> | Dougal Matthews<br /> | d0ugal<br /> | dougal@redhat.com<br /> | UTC+0<br /> | Mistral<br /> |-<br /> | Renat Akhmerov<br /> | rakhmerov<br /> | renat.akhmerov@nokia.com<br /> | UTC+7<br /> | Mistral<br /> |-<br /> | Omer Anson<br /> | oanson<br /> | omer.anson@toganetworks.com<br /> | UTC+2<br /> | [[Dragonflow|DragonFlow]]<br /> |-<br /> | Surya Prakash Singh<br /> | spsurya<br /> | singh.surya64mnnit@gmail.com<br /> | UTC+9<br /> | [[Kolla|Kolla]]<br /> |-<br /> | Daniel Mellado<br /> | dmellado<br /> | dmellado@redhat.com<br /> | UTC+1<br /> | [[Kuryr|Kuryr]]<br /> |-<br /> | Irena Berezovsky<br /> | irenab<br /> | Irena.berezovsky@toganetworks.com<br /> | UTC+2<br /> | [[Kuryr|Kuryr]]<br /> |-<br /> | Mohammed Naser<br /> | mnaser<br /> | mnaser@vexxhost.com<br /> | UTC-5<br /> | Puppet OpenStack<br /> |-<br /> | Ghanshyam Mann<br /> | gmann<br /> | gmann@ghanshyammann.com<br /> | UTC+9<br /> | [[Nova|Nova]]<br /> |-<br /> | Dharmendra Kushwaha<br /> | dkushwaha<br /> | dharmendra.kushwaha@india.nec.com<br /> | UTC+5:30<br /> | [[Tacker|Tacker]]<br /> |-<br /> | Jeffrey Zhang<br /> | Jeffrey4l<br /> | zhang.lei.fly@gmail.com<br /> | UTC+8<br /> | [[Kolla|Kolla]]<br /> |-<br /> |Aditi Sharma<br /> | adisky<br /> | adi.sky17@gmail.com<br /> | UTC+5:30<br /> | [[Watcher|Watcher]]<br /> |-<br /> |Ade Lee<br /> | alee<br /> | alee@redhat.com<br /> | UTC-4<br /> | [[Barbican|Barbican]]<br /> |-<br /> |Lingxian Kong<br /> | lxkong<br /> | anlin.kong@gmail.com<br /> | UTC+12<br /> | [[Qinling|Qinling]]<br /> |-<br /> |Ifat Afek<br /> | ifat_afek<br /> | ifat.afek@nokia.com<br /> | UTC+3<br /> | [[Vitrage|Vitrage]]<br /> |}<br /> <br /> ===Meeting Agenda===<br /> The First Contact SIG team holds public weekly meeting:<br /> <br /> * Channel: &lt;code&gt;&lt;nowiki&gt;#openstack-meeting&lt;/nowiki&gt;&lt;/code&gt;<br /> * Time: Weekly on Wednesday at 800 UTC.<br /> * The meeting minutes of previous meetings can be found here: [http://eavesdrop.openstack.org/meetings/fc_sig/ meeting minutes on eavesdrop]<br /> <br /> <br /> '''Ping list:''' gmann, mattoliverau, cmurphy<br /> <br /> Standing Items:<br /> * New Contributor Patches<br /> ** [https://review.openstack.org/#/q/reviewedby:%22Welcome%252C+new+contributor!+(10068)%22+is:open+-project:+openstack-dev/sandbox+AND+-project:openstack-dev/ci-sandbox Unmerged Patches Not in the sandbox or ci-sandbox]<br /> ** [https://review.openstack.org/#/q/reviewedby:%22Welcome%252C+new+contributor!+(10068)%22 All Changes]<br /> ** https://etherpad.openstack.org/p/FC_SIG_patch_checkup<br /> ** New Contributor the Month<br /> * Ask.openstack.org Contribution Questions<br /> ** [https://ask.openstack.org/en/questions/scope:all/sort:activity-desc/tags:contribution/page:1/ 'Contribution' Tag]<br /> **[https://ask.openstack.org/en/questions/scope:all/sort:activity-desc/tags:contributor/page:1/ 'Contributor' Tag] <br /> ** [https://ask.openstack.org/en/questions/scope:all/sort:activity-desc/tags:community/page:1/ 'Community' Tag]<br /> ** [https://ask.openstack.org/en/questions/scope:all/sort:activity-desc/tags:developer/page:1/ 'Developer' Tag']<br /> ** [https://ask.openstack.org/en/questions/scope:all/sort:activity-desc/tags:development/page:1/ 'Development' Tag]<br /> <br /> <br /> Other Items:<br /> * Forum Recap:<br /> ** Reqs for Organisations Contributing to OpenStack <br /> *** https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21714/drafting-requirements-for-organisations-contributing-to-open<br /> *** https://etherpad.openstack.org/p/Reqs-for-Organisations-Contributing-to-OpenStack<br /> ** FC SIG Ops Inclusion<br /> *** https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21712/first-contact-sig-operator-inclusion<br /> *** https://etherpad.openstack.org/p/FC-SIG-Ops-Inclusion<br /> * Other Ask.O.O Tags<br /> ** basics<br /> ** beginner<br /> ** gettingstarted<br /> ** newbie<br /> ** noob<br /> ** training<br /> ** howto<br /> ** initial<br /> ** interest</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Meetings/Vitrage&diff=161680 2018-06-06T08:02:53Z

<p>Ifat Afek: /* Next Meeting */</p> <hr /> <div>= Weekly Vitrage Meeting =<br /> The [https://launchpad.net/vitrage Vitrage] project team holds a meeting in &lt;code&gt;&lt;nowiki&gt;#openstack-meeting-4&lt;/nowiki&gt;&lt;/code&gt; every week on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=9&amp;min=0&amp;sec=0 0800 UTC].<br /> <br /> Everyone is welcome.<br /> <br /> The blueprints that are used as a basis for [https://launchpad.net/vitrage the Vitrage project] can be found [https://blueprints.launchpad.net/vitrage here].<br /> <br /> <br /> == Next Meeting ==<br /> * Every Wednesday at 0800 UTC<br /> <br /> ===Agenda===<br /> * Current status and progress from last week<br /> * Review action items<br /> * Next steps <br /> * Open Discussion<br /> <br /> == Previous Meetings ==<br /> [http://eavesdrop.openstack.org/meetings/vitrage/2018/ 2018]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2017/ 2017]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2016/ 2016]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2015/ 2015]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Forum/Vancouver2018&diff=161297 2018-05-15T11:23:52Z

<p>Ifat Afek: </p> <hr /> <div>The grand list of all of the Vancouver 2018 [[Forum]] etherpads. Please add links to etherpads below!<br /> <br /> At the Forum the entire OpenStack community (users and developers) gathers to brainstorm the requirements for the next release, gather feedback on the past version and have strategic discussions that go beyond just one release cycle. The Vancouver Forum is the start of the planning phase for the '''Stein''' development cycle. Please prepare session ideas with feedback from the '''Queens''' release in mind.<br /> <br /> See also - [https://www.openstack.org/summit/vancouver-2018/summit-schedule/global-search?t=Forum Full Forum Schedule]<br /> <br /> ===Monday, May 21===<br /> * [1135-1215] Forum 101 https://etherpad.openstack.org/p/YVR-forum-101<br /> * [1135-1215] OpenStack-Chef - Project Onboarding<br /> * [1135-1215] Default Roles<br /> * [1330-1410] Docs/i18n - Project Onboarding https://etherpad.openstack.org/p/docs-i18n-project-onboarding-vancouver<br /> * [1330-1410] Standalone Cinder Introduction<br /> * [1330-1410] Continuing the Migration: Launchpad -&gt; Storyboard https://etherpad.openstack.org/p/continuing-the-migration-lp-sb<br /> * [1330-1410] Users/Operators adoption of QA tools/plugins<br /> * [1440-1500] Tacker - Project Onboarding<br /> * [1440-1500] A New Face and Place for the OpenStack Mentoring Program https://etherpad.openstack.org/p/New-Face-Place-OpenStack-Mentoring<br /> * [1440-1500] Requirements for Resource Reservation https://etherpad.openstack.org/p/YVR18-forum-reservation-requirements<br /> * [1440-1500] Python Testing Interface https://etherpad.openstack.org/p/YVR-python-pti<br /> * [1510-1550] Octavia - Project Onboarding<br /> * [1510-1550] First Contact SIG Operator Inclusion https://etherpad.openstack.org/p/FC-SIG-Ops-Inclusion<br /> * [1510-1550] Building the path to extracting Placement from Nova https://etherpad.openstack.org/p/YVR-placement-extraction<br /> * [1510-1550] Machine Learning for CI Results Analysis https://etherpad.openstack.org/p/YVR-ml-ci-results<br /> * [1620-1700] OpenStack Ansible - Project Onboarding https://etherpad.openstack.org/p/YVR-openstack-ansible for all OpenStack-Ansible activities, including forum.<br /> * [1620-1700] Planning to use Placement in Cinder https://etherpad.openstack.org/p/YVR-cinder-placement<br /> * [1620-1700] Ops/Devs: One community https://etherpad.openstack.org/p/YVR-ops-devs-one-community<br /> * [1620-1700] SDK Testing and Certification<br /> * [1710-1740] Ops Meetups Team: catch-up and PTG merger discussion<br /> * [1710-1740] Keystone - Project Onboarding<br /> * [1710-1740] Cyborg/FPGA Support for Cloud/NFV<br /> * [1710-1740] Python 2 Deprecation Timeline https://etherpad.openstack.org/p/YVR-python-2-deprecation-timeline<br /> <br /> ===Tuesday, May 22===<br /> * [0900-0940] <br /> * [0900-0940] <br /> * [0900-0940] <br /> * [0950-1030] <br /> * [0950-1030] <br /> * [0950-1030] <br /> * [1100-1140] Room 224 - Possible edge architectures for Keystone - https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming<br /> * [1100-1140] Room 220 -Users &amp; Ops feedback for Monasca - https://etherpad.openstack.org/p/monasca-forum-vancouver-topics<br /> * [1100-1140] Room 221-222 - Cinder High Availability (HA) Discussion - https://etherpad.openstack.org/p/YVR18-cinder-ha-forum<br /> * [1150-1230] Room 220 - Ironic Ops and User Feedback - https://etherpad.openstack.org/p/yvr-forum-ironic-ops-and-user-feedback<br /> * [1150-1230] Room 221-222 - Multi-attach Introduction and Future Direction - https://etherpad.openstack.org/p/YVR18-cinder-mutiattach-forum<br /> * [1150-1230] <br /> * [1350-1430] <br /> * [1350-1430] Preemptible instances - the way forward - https://etherpad.openstack.org/p/YVR18-pre-emptible-instances<br /> * [1350-1430] <br /> * [1440-1520] <br /> * [1530-1610] Room 220 - nova/neutron + ops cross-project session - https://etherpad.openstack.org/p/YVR18-novaneutron-ops-cross-project-session<br /> * [1530-1610] <br /> * [1530-1610] <br /> * [1640-1720] Rom 220 - CellsV2 migration process sync with operators - https://etherpad.openstack.org/p/YVR18-cellsv2-migration-sync-with-operators<br /> * [1640-1720] <br /> * [1640-1810] Room 221-222 - Fault Management/Monitoring for NFV/Edge/5G/IoT - https://etherpad.openstack.org/p/YVR-fm-monitoring<br /> * [1730-1810] <br /> * [1730-1810] <br /> * [1730-1810]<br /> <br /> ===Wednesday, May 23===<br /> * [0900-0940] <br /> * [0900-0940] <br /> * [0900-0940] <br /> * [0950-1030] Room 224 - Update on the gaps identified by ETSI NFV in OpenStack - https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained<br /> * [0950-1030] Room 221-222 - Cinder's Documentation Discussion - https://etherpad.openstack.org/p/YVR18-cinder-documentation-forum<br /> * [0950-1030] <br /> * [1100-1140] <br /> * [1100-1140] <br /> * [1100-1140] <br /> * [1150-1230] Room 221-222 - DPDK/SR-IOV NFV Operational issues and way forward - https://etherpad.openstack.org/p/YVR-dpdk-sriov-way-forward<br /> * [1150-1230] <br /> * [1150-1230] <br /> * [1350-1430] <br /> * [1350-1430] <br /> * [1350-1430] <br /> * [1440-1520] Room 220 - Rolling maintenance and upgrade in interaction with VNFM - https://etherpad.openstack.org/p/YVR-rolling-maintenance-with-VNFM<br /> * [1530-1610] <br /> * [1530-1610] <br /> * [1530-1610] <br /> * [1640-1720] Drafting Requirements for Organisations Contributing to Open https://etherpad.openstack.org/p/Reqs-for-Organisations-Contributing-to-OpenStack<br /> * [1640-1720] <br /> * [1640-1720] <br /> * [1730-1810] <br /> * [1730-1810] <br /> * [1730-1810]<br /> <br /> ===Thursday, May 24===<br /> * [0900-0940] Extended Maintenance part I: past, present and future https://etherpad.openstack.org/p/YVR-extended-maintenance<br /> * [0900-0940] <br /> * [0900-0940] <br /> * [0950-1030] Extended Maintenance part II: EM and release cycles https://etherpad.openstack.org/p/YVR-extended-maintenance<br /> * [0950-1030] Room 221-222 [neutron] extend-logging-api https://etherpad.openstack.org/p/extend-logging-api<br /> * [0950-1030] <br /> * [1100-1140] Rm 220 OpenStack is &quot;mature&quot; -- time to get serious on Maintainers https://etherpad.openstack.org/p/YVR-openstack-maintainers-maint-pt3<br /> * [1100-1140] <br /> * [1100-1140] <br /> * [1150-1230] S Release Goals https://etherpad.openstack.org/p/YVR-S-release-goals<br /> * [1150-1230] <br /> * [1150-1230] <br /> * [1350-1430] Official projects and the boundary of &quot;what is OpenStack&quot; https://etherpad.openstack.org/p/YVR-forum-TC-project-boundaries<br /> * [1350-1430] <br /> * [1350-1430] <br /> * [1440-1520] TC Retrospective https://etherpad.openstack.org/p/YVR-tc-retrospective<br /> * [1530-1610] Cross-community governance between OSF projects https://etherpad.openstack.org/p/YVR-cross-osf-tech-governance<br /> * [1530-1610] <br /> * [1540-1610] Advanced RCA use cases - taking Vitrage to the next level https://etherpad.openstack.org/p/YVR-vitrage-advanced-use-cases<br /> * [1640-1720] Vitrage RCA over K8s. Pets and Cattle - Monitor each cow? https://etherpad.openstack.org/p/YVR-vitrage-rca-over-k8s<br /> * [1640-1720] <br /> * [1640-1720] <br /> * [1730-1810] <br /> * [1730-1810] <br /> * [1730-1810]<br /> <br /> ==List of Brainstorming Etherpads (Historical)==<br /> Topic selection is now complete, but see below for session idea brainstorming that was done prior to selection.<br /> <br /> '''These are just kept for historical reference. Please do not use for any additional ideas.'''<br /> <br /> ====Catch-alls====<br /> If you want to post an idea, but aren't working with a specific team or working group, you can use these:<br /> * [https://etherpad.openstack.org/p/YVR-TC-brainstorming Technical Committee Catch-all]<br /> * [https://etherpad.openstack.org/p/YVR-UC-brainstorming User Committee Catch-all]<br /> <br /> ====Etherpads from Teams, Working Groups, and SIGs====<br /> <br /> * [https://etherpad.openstack.org/p/YVR-nova-brainstorming Nova]<br /> * [https://etherpad.openstack.org/p/YVR-cinder-brainstorming Cinder]<br /> * [https://etherpad.openstack.org/p/YVR-glance-brainstorming Glance]<br /> * [https://etherpad.openstack.org/p/YVR-qa-brainstorming QA]<br /> * [https://etherpad.openstack.org/p/YVR-manila-brainstorming Manila]<br /> * [https://etherpad.openstack.org/p/YVR-kolla-brainstorming Kolla]<br /> * [https://etherpad.openstack.org/p/YVR-self-healing-brainstorming Self-healing SIG]<br /> * [https://etherpad.openstack.org/p/FEMDC_Vancouver_brainstorming Fog Edge Massively Distributed Clouds SIG]<br /> * [https://etherpad.openstack.org/p/YVR-openstack-ansible-brainstorming OpenStack-Ansible]<br /> * [https://etherpad.openstack.org/p/YVR-upgrade-brainstorming Upgrade SIG]<br /> * [https://etherpad.openstack.org/p/YVR-publiccloud-wg-brainstorming Public Cloud WG]<br /> * [https://etherpad.openstack.org/p/YVR18-scientific-sig-brainstorming Scientific SIG]<br /> * [https://etherpad.openstack.org/p/YVR-forum-heat-brainstorming Heat]<br /> * [https://etherpad.openstack.org/p/FC_SIG_Rocky_Forum First Contact SIG]<br /> * [https://etherpad.openstack.org/p/YVR-k8s-brainstorming SIG K8s]<br /> * [https://etherpad.openstack.org/p/YVR-stable-brainstorming Stable/Extended Maintenance]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-brainstorming Vitrage]<br /> * [https://etherpad.openstack.org/p/YVR-neutron-brainstorming Neutron]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Forum/Vancouver2018&diff=160522 2018-03-27T15:51:59Z

<p>Ifat Afek: </p> <hr /> <div>The grand list of all of the Vancouver 2018 [[Forum]] etherpads. Please add links to etherpads below!<br /> <br /> At the Forum the entire OpenStack community (users and developers) gathers to brainstorm the requirements for the next release, gather feedback on the past version and have strategic discussions that go beyond just one release cycle. Please prepare session ideas to brainstorm requirements for the next release, gather feedback on the past version and have strategic discussions that go beyond just one release cycle.<br /> <br /> [[File:Forum_lead_up_brainstorming.png]]<br /> <br /> Your ideas are welcome! Either:<br /> * Add a link to an etherpad for all of your team's ideas on this wiki page<br /> * Contribute to the &quot;catch-all&quot; etherpads, linked below.<br /> <br /> and then discuss with everyone to refine and shortlist the best topics.<br /> <br /> Within two weeks, we will call for formal submission of your best ideas.<br /> <br /> ==List of Etherpads==<br /> &lt;big&gt;Forum brainstorming for Vancouver commences March 5th. Please add your etherpad of ideas below!&lt;/big&gt;<br /> <br /> <br /> ====Catch-alls====<br /> If you want to post an idea, but aren't working with a specific team or working group, you can use these:<br /> * [https://etherpad.openstack.org/p/YVR-TC-brainstorming Technical Committee Catch-all]<br /> * [https://etherpad.openstack.org/p/YVR-UC-brainstorming User Committee Catch-all]<br /> <br /> ====Etherpads from Teams, Working Groups, and SIGs====<br /> <br /> * [https://etherpad.openstack.org/p/YVR-nova-brainstorming Nova]<br /> * [https://etherpad.openstack.org/p/YVR-cinder-brainstorming Cinder]<br /> * [https://etherpad.openstack.org/p/YVR-qa-brainstorming QA]<br /> * [https://etherpad.openstack.org/p/YVR-manila-brainstorming Manila]<br /> * [https://etherpad.openstack.org/p/YVR-kolla-brainstorming Kolla]<br /> * [https://etherpad.openstack.org/p/YVR-self-healing-brainstorming Self-healing SIG]<br /> * [https://etherpad.openstack.org/p/FEMDC_Vancouver_brainstorming Fog Edge Massively Distributed Clouds SIG]<br /> * [https://etherpad.openstack.org/p/YVR-openstack-ansible-brainstorming OpenStack-Ansible]<br /> * [https://etherpad.openstack.org/p/YVR-upgrade-brainstorming Upgrade SIG]<br /> * [https://etherpad.openstack.org/p/YVR-publiccloud-wg-brainstorming Public Cloud WG]<br /> * [https://etherpad.openstack.org/p/YVR18-scientific-sig-brainstorming Scientific SIG]<br /> * [https://etherpad.openstack.org/p/YVR-forum-heat-brainstorming Heat]<br /> * [https://etherpad.openstack.org/p/FC_SIG_Rocky_Forum First Contact SIG]<br /> * [https://etherpad.openstack.org/p/YVR-k8s-brainstorming SIG K8s]<br /> * [https://etherpad.openstack.org/p/YVR-stable-brainstorming Stable/Extended Maintenance]<br /> * [https://etherpad.openstack.org/p/YVR-vitrage-brainstorming Vitrage]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Meetings/Vitrage&diff=160330 2018-03-20T13:40:00Z

<p>Ifat Afek: </p> <hr /> <div>= Weekly Vitrage Meeting =<br /> The [https://launchpad.net/vitrage Vitrage] project team holds a meeting in &lt;code&gt;&lt;nowiki&gt;#openstack-meeting-4&lt;/nowiki&gt;&lt;/code&gt; every week on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=9&amp;min=0&amp;sec=0 0800 UTC].<br /> <br /> Everyone is welcome.<br /> <br /> The blueprints that are used as a basis for [https://launchpad.net/vitrage the Vitrage project] can be found [https://blueprints.launchpad.net/vitrage here].<br /> <br /> <br /> == Next Meeting ==<br /> * Every Wednesday at 0900 UTC<br /> <br /> ===Agenda===<br /> * Current status and progress from last week<br /> * Review action items<br /> * Next steps <br /> * Open Discussion<br /> <br /> == Previous Meetings ==<br /> [http://eavesdrop.openstack.org/meetings/vitrage/2018/ 2018]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2017/ 2017]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2016/ 2016]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2015/ 2015]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=File:Vitrage_architecture_queens.png&diff=159352 2018-01-31T08:49:26Z

<p>Ifat Afek: </p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=159351 2018-01-31T08:49:04Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage_architecture_queens.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html low level design]<br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike Virtual PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens Virtual PTG]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=PTG/Rocky/Etherpads&diff=159040 2018-01-18T16:07:03Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> This is the list of etherpads for the Projects Team Gathering in Dublin. Each team can organize the content on their allocated day(s) in the way that seems to most appropriate to them. We suspect most teams will avoid strict timeboxed slots and will use etherpads to list topics to cover. This page lists those etherpads for easy reference.<br /> <br /> For more details on the event, see the [https://www.openstack.org/ptg/ event website].<br /> <br /> Sign up for [https://docs.google.com/spreadsheets/d/1MK7rCgYXCQZP1AgQ0RUiuc-cEXIzW5RuRzz5BWhV4nQ/edit#gid=0 team video interviews].<br /> <br /> For what's happening '''right now''' (during the event), see the [http://ptg.openstack.org/ptg.html ptgbot page].<br /> <br /> '''Projects:''' <br /> * Blazar - https://etherpad.openstack.org/p/blazar-ptg-rocky<br /> * Cinder - https://etherpad.openstack.org/p/cinder-ptg-rocky<br /> * Docs/I18n - https://etherpad.openstack.org/p/docs-i18n-ptg-rocky<br /> * Ironic - https://etherpad.openstack.org/p/ironic-rocky-ptg<br /> * Keystone - https://etherpad.openstack.org/p/keystone-rocky-ptg<br /> * Kolla - https://etherpad.openstack.org/p/kolla-rocky-ptg-planning<br /> * Manila - https://etherpad.openstack.org/p/manila-rocky-ptg<br /> * Mistral - https://etherpad.openstack.org/p/mistral-ptg-rocky<br /> * Monasca - https://etherpad.openstack.org/p/monasca-ptg-rocky<br /> * Neutron - https://etherpad.openstack.org/p/neutron-ptg-rocky<br /> * Nova - https://etherpad.openstack.org/p/nova-ptg-rocky<br /> * Octavia - https://etherpad.openstack.org/p/octavia-ptg-rocky<br /> * Oslo - https://etherpad.openstack.org/p/oslo-ptg-rocky<br /> * Sahara - https://etherpad.openstack.org/p/sahara-rocky-ptg<br /> * TripleO - https://etherpad.openstack.org/p/tripleo-ptg-rocky<br /> * Vitrage - https://etherpad.openstack.org/p/vitrage-ptg-rocky<br /> * Watcher - https://etherpad.openstack.org/p/rocky-watcher-ptg<br /> <br /> <br /> '''SIG/Theme/Other:'''<br /> * First Contact SIG- https://etherpad.openstack.org/p/FC_SIG_Rocky_PTG</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=158038 2017-11-15T15:46:08Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> ==== OpenStack Sydney ====<br /> * [https://www.openstack.org/videos/sydney-2017/advanced-fault-management-with-vitrage-and-mistral Advanced Fault Management with Vitrage and Mistral]<br /> * [https://www.openstack.org/videos/sydney-2017/vitrage-project-updates Vitrage Project Updates]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike Virtual PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens Virtual PTG]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=157257 2017-10-15T11:04:19Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> * [https://etherpad.openstack.org/p/vitrage-pike-design-sessions Pike Virtual PTG]<br /> * [https://etherpad.openstack.org/p/vitrage-ptg-queens Queens Virtual PTG]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=File:Vitrage-high_level_architecture2.png&diff=156020 2017-08-16T08:49:29Z

<p>Ifat Afek: Ifat Afek uploaded a new version of File:Vitrage-high level architecture2.png</p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=155794 2017-08-06T13:28:35Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/devstack-installation.html Devstack Installation]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/configuration.html Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=155793 2017-08-06T13:26:35Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/vitrage/latest/ here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/contributor/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/installation-and-configuration.html Installation and Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=155319 2017-07-16T06:43:26Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [http://docs.openstack.org/developer/vitrage here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://docs.openstack.org/python-vitrageclient/latest/cli.html Vitrage CLI]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/developer/vitrage/installation-and-configuration.html Installation and Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/developer/vitrage/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/developer/vitrage/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=154109 2017-05-17T08:55:42Z

<p>Ifat Afek: /* Quick Demos */</p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos (A bit outdated) ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/developer/vitrage/installation-and-configuration.html Installation and Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/developer/vitrage/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/developer/vitrage/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=154108 2017-05-17T08:54:09Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> <br /> Vitrage documentation can be found [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html here].<br /> <br /> * Usage<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/developer/vitrage/installation-and-configuration.html Installation and Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/developer/vitrage/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/developer/vitrage/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=154107 2017-05-17T08:49:19Z

<p>Ifat Afek: /* Summit Presentations */</p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Sessions ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis Advanced Use Cases for Root Cause Analysis]<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage Project Update Vitrage]<br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/developer/vitrage/installation-and-configuration.html Installation and Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/developer/vitrage/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/developer/vitrage/notifier-aodh-plugin.html Aodh Notifier Design]<br /> ** [https://docs.openstack.org/developer/vitrage/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> <br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=154106 2017-05-17T08:47:45Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === Summit Presentations ===<br /> ==== OpenStack Austin ====<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> ==== OPNFV Berlin ====<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> ==== OpenStack Barcelona ====<br /> * [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]<br /> * [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]<br /> * [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]<br /> ==== OpenStack Boston ====<br /> * [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] <br /> * [https://www.openstack.org/videos/boston-2017/collectd-and-vitrage-integration-an-eventful-presentation Collectd and Vitrage Integration - An Eventful Presentation]<br /> * [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]<br /> * [https://www.openstack.org/videos/boston-2017/advanced-use-cases-for-root-cause-analysis<br /> * [https://www.openstack.org/videos/boston-2017/project-update-vitrage <br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/developer/vitrage/installation-and-configuration.html Installation and Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/developer/vitrage/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/developer/vitrage/notifier-aodh-plugin.html Aodh Notifier Design]<br /> ** [https://docs.openstack.org/developer/vitrage/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> <br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Forum/Boston2017&diff=153782 2017-05-03T15:31:19Z

<p>Ifat Afek: </p> <hr /> <div>The grand list of all of the Boston 2017 Forum etherpads. Please include Date, Time, and links to etherpads when adding new content. An [https://etherpad.openstack.org/p/BOS-forum-moderator-template etherpad template] (optional) is available if you need one.<br /> <br /> <br /> '''See also - [https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146 Full Forum Schedule]'''<br /> <br /> '''See also - [[Forum/Boston2017#Thursday_Afternoon_session_sign-up|Thursday Afternoon session signup]]'''<br /> <br /> '''See also - [https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms Hacking Rooms Schedule]'''<br /> <br /> &lt;div style=&quot;column-count:3;-moz-column-count:3;-webkit-column-count:3&quot;&gt;<br /> __NOTOC__<br /> &lt;/div&gt;<br /> <br /> = Event intro/closure =<br /> * Forum 101 - https://etherpad.openstack.org/p/BOS-forum-101<br /> * Boston feedback session - https://etherpad.openstack.org/p/BOS-summit-feedback<br /> <br /> = Monday =<br /> * [11:15am-11:55am] - Operating the VM and Baremetal platform (1/2) - https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal<br /> * [11:15am-12:45pm] - Nova - Project Onboarding - https://etherpad.openstack.org/p/BOS-forum-nova-project-onboarding<br /> * [12:05pm-12:45pm] - OpenStack documentation: The future depends on all of us - <br /> * [2:00pm-2:40pm] - Evolving the Community Generated Roadmap - https://etherpad.openstack.org/p/BOS-forum-evolving-the-community-generated-roadmap<br /> * [2:50pm-3:30pm] - Evolving the User Survey - https://etherpad.openstack.org/p/BOS-forum-evolving-the-user-survey<br /> * [2:50pm-3:30pm] - Future of Configuration Management - https://etherpad.openstack.org/p/BOS-forum-future-of-configuration-management<br /> * [3:40pm-4:20pm] - Making keystone consumable outside of OpenStack - https://etherpad.openstack.org/p/BOS-forum-consumable-keystone<br /> * [4:40pm-5:20pm] - Next steps for RBAC and policy - https://etherpad.openstack.org/p/BOS-forum-next-steps-for-rbac-and-policy<br /> * [4:40pm-5:20pm] - Should we kill Stackalytics ? - https://etherpad.openstack.org/p/BOS-forum-should-we-kill-stackalytics<br /> <br /> = Tuesday =<br /> * [12:05pm-12:45pm] Enhancing Log Message Headers for RT Debug and Traceability - https://etherpad.openstack.org/p/BOS-forum-log-messages<br /> * [12:05pm-12:45pm] LCOO Roadmap Working Session - https://etherpad.openstack.org/p/BOS-forum-LCOORoadmap<br /> * [2:00pm-2:40pm] ETSI NFV Specs’ Requirements vs OpenStack Reality - https://etherpad.openstack.org/p/BOS-ETSI-NFV-Specs-Reqs-vs-OpenStack-Reality<br /> * [2:00pm-2:40pm] Swift ops feedback session - https://etherpad.openstack.org/p/BOS-Swift-ops-feedback-session<br /> * [2:50pm-3:30pm] Skip-level upgrading - jumping ahead to catch up - https://etherpad.openstack.org/p/BOS-forum-skip-level-upgrading<br /> * [4:40pm-5:20pm] Using Cinder for Nova Ephemeral Storage Backend - https://etherpad.openstack.org/p/BOS-forum-using-cinder-for-nova-ephemeral-storage<br /> * [5:30pm-6:10pm] Features missing in OpenStack core for Public Cloud provider - https://etherpad.openstack.org/p/BOS-forum-Features-Missing-For-Public-Clouds<br /> <br /> = Wednesday =<br /> * [9:00am-9:40am] Oslo developer/operator feedback - https://etherpad.openstack.org/p/BOS-Oslo-brainstorming<br /> * [9:00am-9:40am] Special hardware - https://etherpad.openstack.org/p/BOS-forum-special-hardware<br /> * [9:00am-9:40am] Collaboration between Telecom/NFV related groups - https://etherpad.openstack.org/p/BOS-forum-telecom-nfv-collaboration <br /> * [9:50am-10:30am] oslo.messaging: Recommendations for Non-RabbitMQ Backends - https://etherpad.openstack.org/p/BOS_Forum_Oslo.Messaging_driver_recommendations<br /> * [9:50am-10:30am] Vitrage Usability and New Insights: Where Do We Go Next? - https://etherpad.openstack.org/p/BOS-forum-vitrage-usability-and-new-insights<br /> * [11:00am-11:40am] Compliance/Security Certification for upstream OpenStack - https://etherpad.openstack.org/p/BOS-forum-Compliance-Security-Certification<br /> * [11:00am-11:40am] - Operating the VM and Baremetal platform (2/2) - https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal<br /> * [1:50pm-2:30pm] Kubernetes Ops on OpenStack - https://etherpad.openstack.org/p/BOS-forum-kubernetes-ops-on-openstack<br /> * [1:50pm-2:30pm] App Developer Enablement - https://etherpad.openstack.org/p/BOS-forum-app-dev-enablement<br /> * [1:50pm-2:30pm] Keystone Operator Feedback - https://etherpad.openstack.org/p/BOS-forum-keystone-operator-feedback<br /> * [2:40pm - 3:20pm] Product WG Working Session - https://etherpad.openstack.org/p/BOS-forum-product-wg-working-session<br /> * [5:20pm - 6:00pm] Large Heat Stacks (users/ops/developers) - https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks<br /> <br /> = Thursday =<br /> * [9:00am-9:40am] Users/Operators: Contributing Multi-Project Requirements - https://etherpad.openstack.org/p/BOS-forum-contributing-multi-project-requirements<br /> * [9:00am - 9:40am] Users / Operators adoption of QA tools / plugins - https://etherpad.openstack.org/p/BOS-forum-qa-tools-plugins<br /> * [11:15am-11:55am] - Writing Applications for the VM and Baremetal Platform - https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal<br /> * [11:00am-12:30pm] Queens Goals - https://etherpad.openstack.org/p/BOS-forum-Queens-Goals<br /> * [11:50am-12:30pm] Shared Commercial Goals for OpenStack Public Cloud Providers - https://etherpad.openstack.org/p/BOS-forum-Shared-Commercial-Goals-Public-Clouds<br /> * [2:20pm-3:00pm] Cloud-aware Application Support - https://etherpad.openstack.org/p/pike-forum-cloud-applications<br /> <br /> <br /> ==Thursday Afternoon session sign-up==<br /> If something new comes up during the week, or a session runs over and you need more time, please sign up for another Fishbowl slot on Thursday Afternoon here:<br /> <br /> &lt;div style=&quot;column-count:3;-moz-column-count:3;-webkit-column-count:3&quot;&gt;<br /> * 1:30-2:10 MR102 - available<br /> * 2:20-3:00 MR102 - available<br /> * 3:10-3:50 MR102 - available<br /> * 3:50-4:10 MR102 - available<br /> * 4:10-4:50 MR102 - available<br /> * 5:00-5:40 MR102 - available<br /> * 1:30-2:10 MR103 - available<br /> * 2:20-3:00 MR103 - [https://etherpad.openstack.org/p/pike-forum-cloud-applications Cloud-aware Application Support]<br /> * 3:10-3:50 MR103 - available<br /> * 3:50-4:10 MR103 - available<br /> * 4:10-4:50 MR103 - available<br /> * 5:00-5:40 MR103 - available<br /> * 1:30-2:10 MR104 - available<br /> * 2:20-3:00 MR104 - available<br /> * 3:10-3:50 MR104 - available<br /> * 3:50-4:10 MR104 - available<br /> * 4:10-4:50 MR104 - available<br /> * 5:00-5:40 MR104 - [https://etherpad.openstack.org/p/pike-forum-tc-gathering TC members open gathering]<br /> &lt;/div&gt;<br /> <br /> <br /> ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░<br /> <br /> ==(old) Brainstorming==<br /> Below here were the etherpads used during the agenda brainstorming process...<br /> <br /> ====Catch-alls====<br /> * [https://etherpad.openstack.org/p/BOS-TC-brainstorming TC Catch-all]<br /> * [https://etherpad.openstack.org/p/BOS-UC-brainstorming UC Catch-all]<br /> <br /> ====Project Teams====<br /> <br /> =====Barbican=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Barbican-brainstorming<br /> <br /> =====Cinder=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Cinder-brainstorming<br /> <br /> =====Freezer=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Freezer-brainstorming<br /> <br /> =====Glance=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Glance-brainstorming<br /> <br /> =====Heat=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Heat-brainstorming<br /> <br /> =====I18n=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-I18n-brainstorming<br /> <br /> =====Ironic=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-ironic-brainstorming<br /> <br /> =====Keystone=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Keystone-brainstorming<br /> <br /> =====Nova=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Nova-brainstorming<br /> <br /> =====Oslo=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Oslo-brainstorming<br /> <br /> =====Watcher=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Watcher-brainstorming<br /> <br /> =====QA=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-QA-brainstorming<br /> <br /> =====Swift=====<br /> Brainstorming: https://etherpad.openstack.org/p/BOS-Swift-brainstorming<br /> <br /> ====UC Working Groups ====<br /> <br /> <br /> <br /> =====Telecom/NFV Requirements=====<br /> https://etherpad.openstack.org/p/BOS-UC-brainstorming-Telecom&amp;NFV<br /> <br /> =====Scientific WG=====<br /> https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg<br /> <br /> =====Massively Distributed (Fog/Edge) WG=====<br /> https://etherpad.openstack.org/p/BOS-UC-brainstorming-MassivelyDistributed-Fog-Edge<br /> <br /> =====Public Cloud WG=====<br /> https://etherpad.openstack.org/p/publiccloud-boston-forum-session<br /> <br /> ====Other Working Groups====<br /> <br /> =====VM and Bare-metal platform group=====<br /> <br /> Developer lead group looking for user and operator feedback around the user experience across Nova, Ironic, Cinder and Neutron. Looking at both humans using the system, those operating the system, and projects building on the &quot;VM and Bare-metal&quot; platform. Main activity will be ranking the relative priority of current efforts, and looking to identify any gaps.<br /> <br /> https://etherpad.openstack.org/p/BOS-TC-vm-baremetal-platform</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=File:Vitrage-high_level_architecture2.png&diff=153550 2017-04-25T15:27:01Z

<p>Ifat Afek: Ifat Afek uploaded a new version of File:Vitrage-high level architecture2.png</p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Meetings/Vitrage&diff=152986 2017-04-04T13:56:15Z

<p>Ifat Afek: </p> <hr /> <div>= Weekly Vitrage Meeting =<br /> The [https://launchpad.net/vitrage Vitrage] project team holds a meeting in &lt;code&gt;&lt;nowiki&gt;#openstack-meeting-4&lt;/nowiki&gt;&lt;/code&gt; every week on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=9&amp;min=0&amp;sec=0 0800 UTC].<br /> <br /> Everyone is welcome.<br /> <br /> The blueprints that are used as a basis for [https://launchpad.net/vitrage the Vitrage project] can be found [https://blueprints.launchpad.net/vitrage here].<br /> <br /> <br /> == Next Meeting ==<br /> * Every Wednesday at 0900 UTC<br /> <br /> ===Agenda===<br /> * Current status and progress from last week<br /> * Review action items<br /> * Next steps <br /> * Open Discussion<br /> <br /> == Previous Meetings ==<br /> [http://eavesdrop.openstack.org/meetings/vitrage/2017/ 2017]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2016/ 2016]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2015/ 2015]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Meetings/Vitrage&diff=152984 2017-04-04T13:55:34Z

<p>Ifat Afek: </p> <hr /> <div>= Weekly Vitrage Meeting =<br /> The [https://launchpad.net/vitrage Vitrage] project team holds a meeting in &lt;code&gt;&lt;nowiki&gt;#openstack-meeting-4&lt;/nowiki&gt;&lt;/code&gt; every week on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=9&amp;min=0&amp;sec=0 0800 UTC].<br /> <br /> Everyone is welcome.<br /> <br /> The blueprints that are used as a basis for [https://launchpad.net/vitrage the Vitrage project] can be found [https://blueprints.launchpad.net/vitrage here].<br /> <br /> <br /> == Next Meeting ==<br /> * Every Wednesday at 0900 UTC<br /> <br /> ===Agenda===<br /> * Current status and progress from last week<br /> * Review action items<br /> * Next steps <br /> * Open Discussion<br /> <br /> == Previous Meetings ==<br /> [http://eavesdrop.openstack.org/meetings/vitrage/2015/ 2017]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2016/ 2016]<br /> <br /> [http://eavesdrop.openstack.org/meetings/vitrage/2015/ 2015]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage/RoadMap&diff=152199 2017-03-15T10:16:39Z

<p>Ifat Afek: </p> <hr /> <div>= Vitrage Road Map =<br /> <br /> <br /> '''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage<br /> <br /> <br /> == Pike RoadMap ==<br /> === Must have – design finished by Pike-1 (April 14) ===<br /> * Persistent Graph Database<br /> * Vitrage Installation with TripleO<br /> * Integration with Doctor – Apex installation, test script<br /> * Alarm Deduction use case<br /> * Alarm Aggregation<br /> * Pike Goals (defined by the TC): verify python 3.5<br /> === Very important ===<br /> * API to register on Vitrage notificaitons<br /> * Use cases repository<br /> * Get SNMP alarms? Might not be needed (can be retrieved from Zabbix)<br /> * Improve documentation<br /> === Important === <br /> * Integration with Mistral<br /> * Templates CRUD<br /> * Performance<br /> * Improve the templates language (import)<br /> * Add tests in python-vitrageclient<br /> <br /> <br /> == Ocata RoadMap ==<br /> The following tasks are planned for Ocata:<br /> <br /> * Integration with Aodh: create Vitrage alarms in Aodh. This requires adding a new alarm type in Aodh, see: https://review.openstack.org/#/c/408060<br /> * New collectd-DPDK datasource<br /> * Support Vitrage as part of TripleO installation<br /> * Support Vitrage as Doctor Inspector. Including<br /> ** Installing Vitrage as part of OPNFV Apex installer<br /> ** Supporting Doctor SB API<br /> ** Writing tests for Vitrage<br /> * Refactoring the static datasource, so the yaml file structure will be similar to Vitrage template yaml files<br /> * Refactoring Vitrage ID<br /> <br /> <br /> == Detailed Description == <br /> === Persistent Graph Database ===<br /> Currently Vitrage holds an in-memory graph database, based on NetworkX. If Vitrage is restarted, the graph is rebuilt based on the information that the different datasources provide. <br /> For stability reasons, and also to support RCA history, we would like to introduce a persistent graph database as an alternative to NetworkX (NetworkX can still serve simple deployments and devstacks). One option is Neo4J, but other graph databases can be considered as well.<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph<br /> <br /> === Evaluator Templates CRUD ===<br /> Currently the evaluator templates are loaded when Vitrage is initialized. We would like to have an option to edit the templates at runtime without the need to restart Vitrage.<br /> <br /> A few tasks should be handled:<br /> * Add a persistent storage for the templates<br /> * Upon a template modification, undo the original template and run the new template on all relevant vertices in the graph<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates<br /> <br /> In addition, we would like to supply a UI for smart template editing, that will also validate the template and help the user detect errors.<br /> <br /> <br /> === RCA History ===<br /> Currently Vitrage deletes alarms that are deactivated. Once we have a persistent graph database, we would like to store deleted alarms, together with their causal relationships. Then, the user will be able to detect the root cause of a problem that was already solved (or partially solved; for example, a host fault was fixed, but an application running on one of its instances failed to recover), <br /> <br /> There are a few aspects to consider:<br /> * The logic of root cause representation. If A caused Z, then B caused Z, then A went down... how to represent it?<br /> * Implementation: is storing a big graph the solution? root cause relationship can be stored in other ways as well<br /> * UI representation. How to display the root cause relationship on a time line <br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history<br /> <br /> A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Entity Graph Usability ===<br /> Vitrage Entity Graph in Horizon shows a unique representation of the entire cloud topology, from the physical layer (switches, hosts) to the virtual layer (vms) and to the application layer (Heat stacks). However, when there are many resources the graph can become over crowded. <br /> <br /> This issue was discussed in Barcelona design session, and a few suggestions were raised. See https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Other tasks ===<br /> * Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu<br /> * Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=151509 2017-02-27T10:13:59Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === OpenStack Austin Summit Presentations ===<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> <br /> === OPNFV Berlin Presentations (Collaboration with the Doctor Project) ===<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> <br /> === OpenStack Barcelona Summit Presentations ===<br /> * [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]<br /> * [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]<br /> * [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]<br /> <br /> <br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-first_steps.html Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-api.html Vitrage API]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-template-format.html Evaluator Templates]<br /> ** [https://docs.openstack.org/developer/vitrage/installation-and-configuration.html Installation and Configuration]<br /> * Design Documents<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-graph-design.html Vitrage Graph Design]<br /> ** [https://docs.openstack.org/developer/vitrage/vitrage-use-cases.html Use Cases]<br /> ** [https://docs.openstack.org/developer/vitrage/scenario-evaluator.html Scenario Evaluator]<br /> ** [https://docs.openstack.org/developer/vitrage/notifier-aodh-plugin.html Aodh Notifier Design]<br /> ** [https://docs.openstack.org/developer/vitrage/add-new-datasource.html How to write a new datasource]<br /> <br /> <br /> <br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=151507 2017-02-27T09:52:18Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|450px|thumbnail|right]]<br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === OpenStack Austin Summit Presentations ===<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> <br /> === OPNFV Berlin Presentations (Collaboration with the Doctor Project) ===<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> <br /> === OpenStack Barcelona Summit Presentations ===<br /> * [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]<br /> * [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]<br /> * [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]<br /> <br /> <br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-first_steps.rst Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-api.rst Vitrage API]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst Evaluator Templates]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst Installation and Configuration]<br /> * Design Documents<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst Vitrage Graph Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-use-cases.rst Use Cases]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/scenario-evaluator.rst Scenario Evaluator]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/notifier-aodh-plugin.rst Aodh Notifier Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst How to write a new datasource]<br /> <br /> <br /> <br /> <br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=151506 2017-02-27T09:46:24Z

<p>Ifat Afek: </p> <hr /> <div>__NOTOC__<br /> <br /> [[File:OpenStack_Project_Vitrage_horizontal.png|right]]<br /> <br /> <br /> <br /> &lt;gallery&gt;<br /> &lt;/gallery&gt; <br /> <br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === OpenStack Austin Summit Presentations ===<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> <br /> === OPNFV Berlin Presentations (Collaboration with the Doctor Project) ===<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> <br /> === OpenStack Barcelona Summit Presentations ===<br /> * [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]<br /> * [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]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-first_steps.rst Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-api.rst Vitrage API]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst Evaluator Templates]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst Installation and Configuration]<br /> * Design Documents<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst Vitrage Graph Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-use-cases.rst Use Cases]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/scenario-evaluator.rst Scenario Evaluator]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/notifier-aodh-plugin.rst Aodh Notifier Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst How to write a new datasource]<br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=151505 2017-02-27T09:45:20Z

<p>Ifat Afek: </p> <hr /> <div>&lt;gallery&gt;<br /> [[File:OpenStack_Project_Vitrage_horizontal.png|right]]<br /> &lt;/gallery&gt; <br /> <br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === OpenStack Austin Summit Presentations ===<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> <br /> === OPNFV Berlin Presentations (Collaboration with the Doctor Project) ===<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> <br /> === OpenStack Barcelona Summit Presentations ===<br /> * [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]<br /> * [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]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-first_steps.rst Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-api.rst Vitrage API]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst Evaluator Templates]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst Installation and Configuration]<br /> * Design Documents<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst Vitrage Graph Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-use-cases.rst Use Cases]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/scenario-evaluator.rst Scenario Evaluator]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/notifier-aodh-plugin.rst Aodh Notifier Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst How to write a new datasource]<br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=File:OpenStack_Project_Vitrage_horizontal.png&diff=151504 2017-02-27T09:44:21Z

<p>Ifat Afek: </p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=151503 2017-02-27T09:43:24Z

<p>Ifat Afek: </p> <hr /> <div>&lt;gallery&gt;<br /> File:OpenStack_Project_Vitrage_horizontal.png<br /> &lt;/gallery&gt; <br /> <br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === OpenStack Austin Summit Presentations ===<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> <br /> === OPNFV Berlin Presentations (Collaboration with the Doctor Project) ===<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> <br /> === OpenStack Barcelona Summit Presentations ===<br /> * [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]<br /> * [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]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-first_steps.rst Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-api.rst Vitrage API]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst Evaluator Templates]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst Installation and Configuration]<br /> * Design Documents<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst Vitrage Graph Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-use-cases.rst Use Cases]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/scenario-evaluator.rst Scenario Evaluator]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/notifier-aodh-plugin.rst Aodh Notifier Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst How to write a new datasource]<br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=File:Vitrage-high_level_architecture2.png&diff=151491 2017-02-26T12:08:31Z

<p>Ifat Afek: Ifat Afek uploaded a new version of File:Vitrage-high level architecture2.png</p> <hr /> <div></div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage&diff=145144 2016-12-14T07:44:23Z

<p>Ifat Afek: </p> <hr /> <div>&lt;gallery&gt;<br /> File:Vitrage logo finaly.png<br /> &lt;/gallery&gt; <br /> <br /> <br /> == What is Vitrage? ==<br /> Vitrage is the OpenStack RCA (Root Cause Analysis) service for organizing, analyzing and expanding OpenStack alarms &amp; events, yielding insights regarding the root cause of problems and deducing their existence before they are directly detected.<br /> <br /> === High Level Functionality ===<br /> # Physical-to-Virtual entities mapping<br /> # Deduced alarms and states (i.e., raising an alarm or modifying a state based on analysis of the system, instead of direct monitoring)<br /> # Root Cause Analysis (RCA) for alarms/events<br /> # Horizon plugin for the above features<br /> <br /> <br /> <br /> == High Level Architecture ==<br /> <br /> [[File:Vitrage-high level architecture2.png|2000px|frameless|center|Vitrage High Level Architecture]] &lt;br /&gt;<br /> <br /> <br /> '''Vitrage Data Source(s).''' Responsible for importing information from different sources, regarding the state of the system. This includes information regarding resources both physical &amp; 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. <br /> <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).<br /> <br /> '''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.<br /> <br /> For more information, refer to the [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst low level design]<br /> <br /> <br /> <br /> == Use Cases ==<br /> === Baseline ===<br /> [[File:Rca-baseline.jpg|400px|frameless|right|Baseline]] &lt;br /&gt;<br /> <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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Deduced alarms &amp; states ===<br /> [[File:DeducedAlarm.jpg|500px|frameless|right|Deduced Alarm]] &lt;br /&gt;<br /> <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:<br /> <br /> 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 &quot;ERROR&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> === Root Cause Indicators ===<br /> [[File:RootCauseExample.jpg|500px|frameless|right|Root Cause Link]] &lt;br /&gt;<br /> <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.<br /> <br /> 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:<br /> <br /> Once the local &quot;causes&quot; 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.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> == Demos and Presentations ==<br /> === Quick Demos ===<br /> * [[Media:Vitrage presentation Feb 09.pdf|Vitrage Presentation]]<br /> * [https://www.youtube.com/watch?v=tl5AD5IdzMo&amp;feature=youtu.be Vitrage Functionalities Overview]<br /> * [https://www.youtube.com/watch?v=GyTnMw8stXQ&amp;feature=youtu.be Vitrage Get Topology Demo]<br /> * [https://www.youtube.com/watch?v=w1XQATkrdmg Vitrage Alarms Demo]<br /> * [https://www.youtube.com/watch?v=vqlOKTmYR4c Vitrage Deduced Alarms and RCA Demo]<br /> <br /> === OpenStack Austin Summit Presentations ===<br /> * [https://www.youtube.com/watch?v=9Qw5coTLgMo Project Vitrage How to Organize, Analyze and Visualize your OpenStack Cloud]<br /> * [https://www.youtube.com/watch?v=ey68KNKXc5c On the Path to Telco Cloud Openness: Nokia CloudBand Vitrage &amp; OPNFV Doctor collaboration]<br /> <br /> === OPNFV Berlin Presentations (Collaboration with the Doctor Project) ===<br /> * [https://www.youtube.com/watch?v=qV4eLhsFR28 Failure Inspection in Doctor utilizing Vitrage and Congress]<br /> * [https://www.youtube.com/watch?v=xutITYoZKhE Doctor: fast and dynamic fault management in OpenStack (DOCOMO, NTT, NEC, Nokia, Intel) - Telecom TV]<br /> <br /> === OpenStack Barcelona Summit Presentations ===<br /> * [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]<br /> * [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]<br /> * [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]<br /> <br /> <br /> == Development (Blueprints, Roadmap, Design...) ==<br /> * Project at Launchpad: http://launchpad.net/vitrage<br /> * [https://blueprints.launchpad.net/vitrage Blueprints]<br /> * [https://wiki.openstack.org/wiki/Vitrage/RoadMap Road Map]<br /> * Source code:<br /> ** [https://github.com/openstack/vitrage vitrage]<br /> ** [https://github.com/openstack/python-vitrageclient python-vitrageclient]<br /> ** [https://github.com/openstack/vitrage-dashboard vitrage-dashboard]<br /> <br /> === Design Discussions ===<br /> * [https://etherpad.openstack.org/p/vitrage-overlapping-templates-support-design Supporting Overlapping Templates]<br /> * [https://etherpad.openstack.org/p/vitrage-barcelona-design-summit Barcelona Design Summit]<br /> <br /> === Documention ===<br /> * Usage<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-first_steps.rst Getting Started Guide]<br /> ** [https://github.com/openstack/python-vitrageclient/blob/master/doc/source/cli.rst Vitrage CLI]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-api.rst Vitrage API]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst Evaluator Templates]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/installation-and-configuration.rst Installation and Configuration]<br /> * Design Documents<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-graph-design.rst Vitrage Graph Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-use-cases.rst Use Cases]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/scenario-evaluator.rst Scenario Evaluator]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/notifier-aodh-plugin.rst Aodh Notifier Design]<br /> ** [https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst How to write a new datasource]<br /> <br /> == Communication and Meetings ==<br /> === Meetings ===<br /> * Weekly on Wednesday at 0800 UTC in #openstack-meeting-4 at freenode<br /> * Check [https://wiki.openstack.org/wiki/Meetings/Vitrage Vitrage Meetings] for more details<br /> <br /> === Contact Us ===<br /> * IRC channel for regular daily discussions: #openstack-vitrage<br /> * Use [Vitrage] tag for Vitrage emails on [http://lists.openstack.org/pipermail/openstack-dev/ OpenStack Mailing Lists]</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage/RoadMap&diff=145143 2016-12-14T07:42:11Z

<p>Ifat Afek: </p> <hr /> <div>= Vitrage Road Map =<br /> <br /> <br /> '''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage<br /> <br /> <br /> == Plans for Ocata ==<br /> The following tasks are planned for Ocata:<br /> <br /> * Integration with Aodh: create Vitrage alarms in Aodh. This requires adding a new alarm type in Aodh, see: https://review.openstack.org/#/c/408060<br /> * New collectd-DPDK datasource<br /> * Support Vitrage as part of TripleO installation<br /> * Support Vitrage as Doctor Inspector. Including<br /> ** Installing Vitrage as part of OPNFV Apex installer<br /> ** Supporting Doctor SB API<br /> ** Writing tests for Vitrage<br /> * Refactoring the static datasource, so the yaml file structure will be similar to Vitrage template yaml files<br /> * Refactoring Vitrage ID<br /> <br /> <br /> == Backlog == <br /> === Persistent Graph Database ===<br /> Currently Vitrage holds an in-memory graph database, based on NetworkX. If Vitrage is restarted, the graph is rebuilt based on the information that the different datasources provide. <br /> For stability reasons, and also to support RCA history, we would like to introduce a persistent graph database as an alternative to NetworkX (NetworkX can still serve simple deployments and devstacks). One option is Neo4J, but other graph databases can be considered as well.<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph<br /> <br /> <br /> === RCA History ===<br /> Currently Vitrage deletes alarms that are deactivated. Once we have a persistent graph database, we would like to store deleted alarms, together with their causal relationships. Then, the user will be able to detect the root cause of a problem that was already solved (or partially solved; for example, a host fault was fixed, but an application running on one of its instances failed to recover), <br /> <br /> There are a few aspects to consider:<br /> * The logic of root cause representation. If A caused Z, then B caused Z, then A went down... how to represent it?<br /> * Implementation: is storing a big graph the solution? root cause relationship can be stored in other ways as well<br /> * UI representation. How to display the root cause relationship on a time line <br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history<br /> <br /> A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Entity Graph Usability ===<br /> Vitrage Entity Graph in Horizon shows a unique representation of the entire cloud topology, from the physical layer (switches, hosts) to the virtual layer (vms) and to the application layer (Heat stacks). However, when there are many resources the graph can become over crowded. <br /> <br /> This issue was discussed in Barcelona design session, and a few suggestions were raised. See https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Evaluator Templates CRUD ===<br /> Currently the evaluator templates are loaded when Vitrage is initialized. We would like to have an option to edit the templates at runtime without the need to restart Vitrage.<br /> <br /> A few tasks should be handled:<br /> * Add a persistent storage for the templates<br /> * Upon a template modification, undo the original template and run the new template on all relevant vertices in the graph<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates<br /> <br /> In addition, we would like to supply a UI for smart template editing, that will also validate the template and help the user detect errors.<br /> <br /> <br /> === Other tasks ===<br /> * Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu<br /> * Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage/RoadMap&diff=145142 2016-12-14T07:36:20Z

<p>Ifat Afek: </p> <hr /> <div>= Vitrage Road Map =<br /> <br /> <br /> '''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage<br /> <br /> <br /> == Plans for Ocata ==<br /> The following tasks are planned for Ocata<br /> <br /> * Integration with Aodh: create Vitrage alarms in Aodh. This requires adding a new alarm type in Aodh, see: https://review.openstack.org/#/c/408060<br /> * New collectd-DPDK datasource<br /> * Support Vitrage as part of TripleO installation<br /> * Support Vitrage as Doctor Inspector. Including<br /> ** Installing Vitrage as part of OPNFV Apex installer<br /> ** Supporting Doctor SB API<br /> ** Writing tests for Vitrage<br /> * Refactoring the static datasource, so the yaml file structure will be similar to Vitrage template yaml files<br /> * Refactoring Vitrage ID<br /> <br /> <br /> == Backlog == <br /> === Persistent Graph Database ===<br /> Currently Vitrage holds an in-memory graph database, based on NetworkX. If Vitrage is restarted, the graph is rebuilt based on the information that the different datasources provide. <br /> For stability reasons, and also to support RCA history, we would like to introduce a persistent graph database as an alternative to NetworkX (NetworkX can still serve simple deployments and devstacks). One option is Neo4J, but other graph databases can be considered as well.<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph<br /> <br /> <br /> === RCA History ===<br /> Currently Vitrage deletes alarms that are deactivated. Once we have a persistent graph database, we would like to store deleted alarms, together with their causal relationships. Then, the user will be able to detect the root cause of a problem that was already solved (or partially solved; for example, a host fault was fixed, but an application running on one of its instances failed to recover), <br /> <br /> There are a few aspects to consider:<br /> * The logic of root cause representation. If A caused Z, then B caused Z, then A went down... how to represent it?<br /> * Implementation: is storing a big graph the solution? root cause relationship can be stored in other ways as well<br /> * UI representation. How to display the root cause relationship on a time line <br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history<br /> <br /> A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Entity Graph Usability ===<br /> Vitrage Entity Graph in Horizon shows a unique representation of the entire cloud topology, from the physical layer (switches, hosts) to the virtual layer (vms) and to the application layer (Heat stacks). However, when there are many resources the graph can become over crowded. <br /> <br /> This issue was discussed in Barcelona design session, and a few suggestions were raised. See https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Evaluator Templates CRUD ===<br /> Currently the evaluator templates are loaded when Vitrage is initialized. We would like to have an option to edit the templates at runtime without the need to restart Vitrage.<br /> <br /> A few tasks should be handled:<br /> * Add a persistent storage for the templates<br /> * Upon a template modification, undo the original template and run the new template on all relevant vertices in the graph<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates<br /> <br /> In addition, we would like to supply a UI for smart template editing, that will also validate the template and help the user detect errors.<br /> <br /> <br /> === Other tasks ===<br /> * Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu<br /> * Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage/RoadMap&diff=145140 2016-12-14T07:33:19Z

<p>Ifat Afek: </p> <hr /> <div>= Vitrage Road Map =<br /> <br /> '''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage<br /> <br /> == Plans for Ocata ==<br /> The following tasks are planned for Ocata<br /> <br /> * Integration with Aodh: create Vitrage alarms in Aodh. This requires adding a new alarm type in Aodh, see: https://review.openstack.org/#/c/408060<br /> * New collectd-DPDK datasource<br /> * Support Vitrage as part of TripleO installation<br /> * Support Vitrage as Doctor Inspector. Including<br /> ** Installing Vitrage as part of OPNFV Apex installer<br /> ** Supporting Doctor SB API<br /> ** Writing tests for Vitrage<br /> * Refactoring the static datasource, so the yaml file structure will be similar to Vitrage template yaml files<br /> * Refactoring Vitrage ID<br /> <br /> <br /> == Backlog == <br /> === Persistent Graph Database ===<br /> Currently Vitrage holds an in-memory graph database, based on NetworkX. If Vitrage is restarted, the graph is rebuilt based on the information that the different datasources provide. <br /> For stability reasons, and also to support RCA history, we would like to introduce a persistent graph database as an alternative to NetworkX (NetworkX can still serve simple deployments and devstacks). One option is Neo4J, but other graph databases can be considered as well.<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph<br /> <br /> <br /> === RCA History ===<br /> Currently Vitrage deletes alarms that are deactivated. Once we have a persistent graph database, we would like to store deleted alarms, together with their causal relationships. Then, the user will be able to detect the root cause of a problem that was already solved (or partially solved; for example, a host fault was fixed, but an application running on one of its instances failed to recover), <br /> <br /> There are a few aspects to consider:<br /> * The logic of root cause representation. If A caused Z, then B caused Z, then A went down... how to represent it?<br /> * Implementation: is storing a big graph the solution? root cause relationship can be stored in other ways as well<br /> * UI representation. How to display the root cause relationship on a time line <br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history<br /> <br /> A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Entity Graph Usability ===<br /> Vitrage Entity Graph in Horizon shows a unique representation of the entire cloud topology, from the physical layer (switches, hosts) to the virtual layer (vms) and to the application layer (Heat stacks). However, when there are many resources the graph can become over crowded. <br /> <br /> This issue was discussed in Barcelona design session, and a few suggestions were raised. See https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> <br /> === Evaluator Templates CRUD ===<br /> Currently the evaluator templates are loaded when Vitrage is initialized. We would like to have an option to edit the templates at runtime without the need to restart Vitrage.<br /> <br /> A few tasks should be handled:<br /> * Add a persistent storage for the templates<br /> * Upon a template modification, undo the original template and run the new template on all relevant vertices in the graph<br /> <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates<br /> <br /> In addition, we would like to supply a UI for smart template editing, that will also validate the template and help the user detect errors.<br /> <br /> <br /> === Other tasks ===<br /> * Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu<br /> * Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage/RoadMap&diff=145139 2016-12-14T07:31:26Z

<p>Ifat Afek: </p> <hr /> <div>= Vitrage Road Map =<br /> <br /> '''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage<br /> <br /> == Plans for Ocata ==<br /> The following tasks are planned for Ocata<br /> <br /> * Integration with Aodh: create Vitrage alarms in Aodh. This requires adding a new alarm type in Aodh, see: https://review.openstack.org/#/c/408060<br /> * New collectd-DPDK datasource<br /> * Support Vitrage as part of TripleO installation<br /> * Support Vitrage as Doctor Inspector. Including<br /> ** Installing Vitrage as part of OPNFV Apex installer<br /> ** Supporting Doctor SB API<br /> ** Writing tests for Vitrage<br /> * Refactoring the static datasource, so the yaml file structure will be similar to Vitrage template yaml files<br /> * Refactoring Vitrage ID<br /> <br /> <br /> == Backlog == <br /> === Persistent Graph Database ===<br /> Currently Vitrage holds an in-memory graph database, based on NetworkX. If Vitrage is restarted, the graph is rebuilt based on the information that the different datasources provide. <br /> For stability reasons, and also to support RCA history, we would like to introduce a persistent graph database as an alternative to NetworkX (NetworkX can still serve simple deployments and devstacks). One option is Neo4J, but other graph databases can be considered as well.<br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph<br /> <br /> === RCA History ===<br /> Currently Vitrage deletes alarms that are deactivated. Once we have a persistent graph database, we would like to store deleted alarms, together with their causal relationships. Then, the user will be able to detect the root cause of a problem that was already solved (or partially solved; for example, a host fault was fixed, but an application running on one of its instances failed to recover), <br /> <br /> There are a few aspects to consider:<br /> * The logic of root cause representation. If A caused Z, then B caused Z, then A went down... how to represent it?<br /> * Implementation: is storing a big graph the solution? root cause relationship can be stored in other ways as well<br /> * UI representation. How to display the root cause relationship on a time line <br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history<br /> A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> === Entity Graph Usability ===<br /> Vitrage Entity Graph in Horizon shows a unique representation of the entire cloud topology, from the physical layer (switches, hosts) to the virtual layer (vms) and to the application layer (Heat stacks). However, when there are many resources the graph can become over crowded. <br /> <br /> This issue was discussed in Barcelona design session, and a few suggestions were raised. See https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> === Evaluator Templates CRUD ===<br /> Currently the evaluator templates are loaded when Vitrage is initialized. We would like to have an option to edit the templates at runtime without the need to restart Vitrage.<br /> <br /> A few tasks should be handled:<br /> * Add a persistent storage for the templates<br /> * Upon a template modification, undo the original template and run the new template on all relevant vertices in the graph<br /> <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates<br /> <br /> In addition, we would like to supply a UI for smart template editing, that will also validate the template and help the user detect errors.<br /> <br /> === Other tasks ===<br /> * Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu<br /> * Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications</div>

Ifat Afek https://wiki.openstack.org/w/index.php?title=Vitrage/RoadMap&diff=145138 2016-12-14T07:28:24Z

<p>Ifat Afek: Created page with &quot;'''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage == Plans for Ocata == The following tasks are plann...&quot;</p> <hr /> <div>'''Note''': all blueprints for the tasks below can be found in Vitrage launchpad: https://blueprints.launchpad.net/vitrage<br /> <br /> == Plans for Ocata ==<br /> The following tasks are planned for Ocata<br /> * Integration with Aodh: create Vitrage alarms in Aodh. This requires adding a new alarm type in Aodh, see: https://review.openstack.org/#/c/408060<br /> * New collectd-DPDK datasource<br /> * Support Vitrage as part of TripleO installation<br /> * Support Vitrage as Doctor Inspector. Including<br /> ** Installing Vitrage as part of OPNFV Apex installer<br /> ** Supporting Doctor SB API<br /> ** Writing tests for Vitrage<br /> * Refactoring the static datasource, so the yaml file structure will be similar to Vitrage template yaml files<br /> * Refactoring Vitrage ID<br /> <br /> <br /> == Backlog == <br /> === Persistent Graph Database ===<br /> Currently Vitrage holds an in-memory graph database, based on NetworkX. If Vitrage is restarted, the graph is rebuilt based on the information that the different datasources provide. <br /> For stability reasons, and also to support RCA history, we would like to introduce a persistent graph database as an alternative to NetworkX (NetworkX can still serve simple deployments and devstacks). One option is Neo4J, but other graph databases can be considered as well.<br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/persistent-entity-graph<br /> <br /> === RCA History ===<br /> Currently Vitrage deletes alarms that are deactivated. Once we have a persistent graph database, we would like to store deleted alarms, together with their causal relationships. Then, the user will be able to detect the root cause of a problem that was already solved (or partially solved; for example, a host fault was fixed, but an application running on one of its instances failed to recover), <br /> There are a few aspects to consider:<br /> The logic of root cause representation. If A caused Z, then B caused Z, then A went down... how to represent it?<br /> Implementation: is storing a big graph the solution? root cause relationship can be stored in other ways as well<br /> UI representation. How to display the root cause relationship on a time line <br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/rca-history<br /> A discussion during Barcelona design summit: https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> === Entity Graph Usability ===<br /> Vitrage Entity Graph in Horizon shows a unique representation of the entire cloud topology, from the physical layer (switches, hosts) to the virtual layer (vms) and to the application layer (Heat stacks). However, when there are many resources the graph can become over crowded. <br /> This issue was discussed in Barcelona design session, and a few suggestions were raised. See https://etherpad.openstack.org/p/vitrage-barcelona-design-summit<br /> <br /> === Evaluator Templates CRUD ===<br /> Currently the evaluator templates are loaded when Vitrage is initialized. We would like to have an option to edit the templates at runtime without the need to restart Vitrage.<br /> A few tasks should be handled:<br /> Add a persistent storage for the templates<br /> Upon a template modification, undo the original template and run the new template on all relevant vertices in the graph<br /> Blueprint: https://blueprints.launchpad.net/vitrage/+spec/crud-templates<br /> <br /> In addition, we would like to supply a UI for smart template editing, that will also validate the template and help the user detect errors.<br /> <br /> === Other tasks ===<br /> Implement a Sensu datasource: https://blueprints.launchpad.net/vitrage/+spec/datasource-sensu<br /> Configurable notifications: https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications</div>

Ifat Afek