openstack/vitrage
Code Issues Proposed changes

Merge "Beautify, correct URLs in documentation files"

Browse Source
This commit is contained in:
Jenkins 2016-11-23 10:27:36 +00:00 committed by Gerrit Code Review
commit 4d3e5ada85
14 changed files with 196 additions and 191 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.rst
View File

@ -8,12 +8,12 @@ Vitrage is the OpenStack RCA (Root Cause Analysis) Service for organizing, analy
Enabling Vitrage in DevStack Enabling Vitrage in DevStack
---------------------------- ----------------------------
see `README file <https://github.com/openstack/vitrage/blob/master/devstack/README.rst/>`_ More details in: `README file <devstack/README.rst>`_
Project Resources Project Resources
----------------- -----------------
* wiki page: https://wiki.openstack.org/wiki/Vitrage * Wiki page: https://wiki.openstack.org/wiki/Vitrage
* Launchpad: https://launchpad.net/vitrage * Launchpad: https://launchpad.net/vitrage
* Source: http://git.openstack.org/cgit/openstack/vitrage * Source: http://git.openstack.org/cgit/openstack/vitrage

76
doc/source/add-new-datasource.rst
View File

@ -9,19 +9,19 @@ In order to add a new datasource to Vitrage do the following steps:
1. Have your datasource enclosed in a package with the datasources' name and 1. Have your datasource enclosed in a package with the datasources' name and
put it under 'vitrage.datasources', For example: put it under 'vitrage.datasources', For example:
vitrage.datasource.cinder.volume. ``vitrage.datasource.cinder.volume``.
2. Under your datasource package, have both your datasources' driver class 2. Under your datasource package, have both your datasources' driver class
and your datasources' transformer class. See below for details on those and your datasources' transformer class. See below for details on those
classes. classes.
3. Under your datasources' package __init__.py you must import cfg 3. Under your datasources' package ``__init__.py`` you must import ``cfg``
from oslo_config and declare a list named OPTS. Under OPTS, you can define from ``oslo_config`` and declare a list named ``OPTS``. Under ``OPTS``, you can define
your needed options using the oslo_config.cfg module. your needed options using the ``oslo_config.cfg`` module.
There are three options you must have: There are three options you must have:
a. Driver and transformer with the path to your driver and transformer a. Driver and transformer with the path to your driver and transformer
classes respectively. classes respectively.
b. update_method property that describes the type of update mechanism for b. ``update_method`` property that describes the type of update mechanism for
this datasource. The options are: push, pull or none. this datasource. The options are (string): push, pull or none.
c. In addition to those three, you may add any other configuration options c. In addition to those three, you may add any other configuration options
you may need for your datasource. you may need for your datasource.
@ -32,19 +32,18 @@ In order to add a new datasource to Vitrage do the following steps:
devstack is installed, you need to add it to the 'types' property in the devstack is installed, you need to add it to the 'types' property in the
datasources section in the configuration. To do so, do the following: datasources section in the configuration. To do so, do the following:
a. add the datasource name to the types property in the "devstack.settings" a. add the datasource name to the types property in the ``devstack.settings``
file. file.
b. if the datasource is not one of the main and basic projects of devstack, b. if the datasource is not one of the main and basic projects of devstack,
add the following data in the "devstack.plugin.sh" file": add the following data in the ``devstack.plugin.sh`` file":
# remove <datasource_name> vitrage datasource if <datasource_name> .. code:: bash
datasource not installed
if ! is_service_enabled <datasource_name>; then # remove <datasource_name> vitrage datasource if <datasource_name> datasource not installed
disable_vitrage_datasource <datasource_name> if ! is_service_enabled <datasource_name>; then
disable_vitrage_datasource <datasource_name>
fi fi
6. You are done! 6. You are done!
@ -56,14 +55,14 @@ Entities in this context refer both to resources (physical, virtual,
applicative) and alarms (Aodh, Nagios, Zabbix, Monasca, etc.) applicative) and alarms (Aodh, Nagios, Zabbix, Monasca, etc.)
The datasource has two modes of action: The datasource has two modes of action:
1. get_all (snapshot): Query all entities and send events to the vitrage 1. ``get_all`` (snapshot): Query all entities and send events to the vitrage
events queue. events queue.
When done for the first time, send an "end" event to inform it has finished When done for the first time, send an "end" event to inform it has finished
the get_all for the datasource (because it is done asynchronously). the get_all for the datasource (because it is done asynchronously).
2. notify: Send an event to the vitrage events queue upon any change. 2. ``notify``: Send an event to the vitrage events queue upon any change.
This can be done in two ways: This can be done in two ways:
a. Built in polling mechanism called get_changes. a. Built in polling mechanism called ``get_changes``.
b. Built in pushing mechanism using the oslo bus. b. Built in pushing mechanism using the oslo bus.
A driver should inherit from 'vitrage.datasources.driver_base.DriverBase' class A driver should inherit from 'vitrage.datasources.driver_base.DriverBase' class
@ -88,7 +87,7 @@ _________________
The Transformer class understands the specific entity details and outputs a The Transformer class understands the specific entity details and outputs a
tuple with the following details: tuple with the following details:
1. The vertex with its new details to be added / updated / deleted. 1. The vertex with its new details to be added/updated/deleted.
2. List of tuples where each tuple consists of: 2. List of tuples where each tuple consists of:
a. Neighbor vertex with it's partial data so vitrage will know to where a. Neighbor vertex with it's partial data so vitrage will know to where
@ -97,7 +96,7 @@ tuple with the following details:
Note that for every driver there should be a matching Transformer. Note that for every driver there should be a matching Transformer.
A transformer should inherit from A transformer should inherit from
'vitrage.datasoures.transformer_base.TransformerBase' class and ``vitrage.datasoures.transformer_base.TransformerBase`` class and
must implement the following methods: must implement the following methods:
+----------------------------------+------------------------------------+----------------------------------------+ +----------------------------------+------------------------------------+----------------------------------------+
@ -138,7 +137,7 @@ Holds the following fields:
**Example** **Example**
Datasource __init__.py OPTS: Datasource ``__init__.py OPTS``:
.. code:: python .. code:: python
@ -168,23 +167,25 @@ Datasource __init__.py OPTS:
Instantiation flow Instantiation flow
------------------ ------------------
Now, when loading Vitrage, vitrage.datasources.launcher.Launcher Now, when loading Vitrage, ``vitrage.datasources.launcher.Launcher``
will get instantiated and will register all of the datasources will get instantiated and will register all of the datasources
into Vitrage. Note, that if you want your datasource to also run as a into Vitrage. **Note**: if you want your datasource to also run as a
service i.e. get changes every <interval> you need to set under your service i.e. get changes every <interval> you need to set under your
datasources' OPTS an Integer option named 'changes_interval'. datasources ``OPTS`` an ``Integer`` option named ``changes_interval``.
Additionally, vitrage.entity_graph.transformer_manager.TransformerManager
Additionally, ``vitrage.entity_graph.transformer_manager.TransformerManager``
will get instantiated and will register all of the datasources transformers will get instantiated and will register all of the datasources transformers
into Vitrage. into Vitrage.
These two steps are using your previously configured driver and These two steps are using your previously configured driver and
transformer path options under your datasources' package __init__.OPTS. transformer path options under your datasources' package ``__init__.OPTS``.
Datasource Configuration Options Datasource Configuration Options
-------------------------------- --------------------------------
Any option your datasource defined can be accessed using oslo_config.cfg Any option your datasource defined can be accessed using ``oslo_config.cfg``
or by configuring vitrage.conf. or by configuring ``vitrage.conf``.
**Example** **Example**
@ -195,26 +196,23 @@ or by configuring vitrage.conf.
**Example** **Example**
/etc/vitrage/vitrage.conf .. code::
# /etc/vitrage/vitrage.conf
... ...
[datasources] [datasources]
snapshots_interval = 300 snapshots_interval = 300
# Names of supported plugins (list value) # Names of supported plugins (list value)
types = nagios,zabbix,nova.host,nova.instance,nova.zone,static_physical,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
types = nova.host,nova.instance,nova.zone,static_physical,nagios,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
[zabbix] [zabbix]
url = http://<ip>/zabbix
url = http://135.248.18.30
password = zabbix password = zabbix
user = admin user = admin
config_file = /etc/vitrage/zabbix_conf.yaml config_file = /etc/vitrage/zabbix_conf.yaml
[nagios]
user = omdadmin
password = omd
url = http://<ip>:<port>/<site>/nagios/cgi-bin/status.cgi
config_file = /etc/vitrage/nagios_conf.yaml

18
doc/source/alarm-severity-config.rst
View File

@ -16,8 +16,9 @@ Since each data-source might represent severity differently, for each
data-source we can supply it's own mapping to the aggregated severity supported data-source we can supply it's own mapping to the aggregated severity supported
in Vitrage. This way we can know which severity is more important. in Vitrage. This way we can know which severity is more important.
In addition we also normalize the severities for the horizon UI (called In addition we also normalize the severities for the horizon UI (called
operational_severity) in order for the UI to know what color to show in ``operational_severity``) in order for the UI to know what color to show in
Horizon. Horizon.
This page explains how to handle this mapping for a given This page explains how to handle this mapping for a given
data-source. data-source.
@ -66,12 +67,10 @@ Default Configuration
Default configurations for alarms severities will be installed with Vitrage for Default configurations for alarms severities will be installed with Vitrage for
all the pre-packaged data-sources. all the pre-packaged data-sources.
Format Format
++++++ ++++++
::
.. code:: yaml
category: ALARM category: ALARM
values: values:
@ -79,13 +78,11 @@ Format
priority: <Alarm severity priority - an integer> priority: <Alarm severity priority - an integer>
original values: original values:
- name: <Original alarm severity name> - name: <Original alarm severity name>
operational_value: <normalized alarm severity - from operational_value: <normalized alarm severity - from OperationalAlarmSeverity class>
OperationalAlarmSeverity class>
- name: ... # can list several severities for one aggregation - name: ... # can list several severities for one aggregation
- aggregated values: - aggregated values:
priority: ... # can list several aggregated severities priority: ... # can list several aggregated severities
... ...
... ...
@ -93,11 +90,14 @@ Example
+++++++ +++++++
The following file will map alarm severities. The following file will map alarm severities.
For aggregated severity with priority 40 we have 2 severities and each one of For aggregated severity with priority 40 we have 2 severities and each one of
them is mapped to operational severity CRITICAL. them is mapped to operational severity CRITICAL.
For aggregated severity with priority 30 we have 1 severity called WARNING and For aggregated severity with priority 30 we have 1 severity called WARNING and
it is mapped to operational severity WARNING, etc... it is mapped to operational severity WARNING, etc...
::
.. code:: yaml
category: ALARM category: ALARM
values: values:

2
doc/source/conf.py
View File

@ -38,7 +38,7 @@ master_doc = 'index'
# General information about the project. # General information about the project.
project = u'vitrage' project = u'vitrage'
copyright = u'2013, OpenStack Foundation' copyright = u'2016, OpenStack Foundation'
# If true, '()' will be appended to :func: etc. cross-reference text. # If true, '()' will be appended to :func: etc. cross-reference text.
add_function_parentheses = True add_function_parentheses = True

4
doc/source/index.rst
View File

@ -25,7 +25,7 @@ Developer Guide
--------------- ---------------
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1
vitrage-first_steps vitrage-first_steps
vitrage-api vitrage-api
@ -36,7 +36,7 @@ Design Documents
---------------- ----------------
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1
vitrage-graph-design vitrage-graph-design
scenario-evaluator scenario-evaluator

22
doc/source/installation-and-configuration.rst
View File

@ -2,26 +2,30 @@
Installation Installation
============ ============
In order to enable Vitrage: -------------------------------
Enable Vitrage and data sources
-------------------------------
* `Enabling Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst/>`_ * `Enabling Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst>`_
* `Enabling Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst/>`_ * `Enabling Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst>`_
* `Nagios devstack installation <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-devstack-installation.rst/>`_ * `Nagios devstack installation <http://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html>`_
* `Zabbix devstack installation <http://docs.openstack.org/developer/vitrage/zabbix_vitrage.html>`_
------------- -------------
Configuration Configuration
------------- -------------
* `Nagios Plugin Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-config.rst>`_ * `Nagios Plugin Configuration <http://docs.openstack.org/developer/vitrage/nagios-config.html>`_
* `Static Physical Plugin Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/static-physical-config.rst>`_ * `Static Physical Plugin Configuration <http://docs.openstack.org/developer/vitrage/static-physical-config.html>`_
* `Resource State Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/resource-state-config.rst>`_ * `Resource State Configuration <http://docs.openstack.org/developer/vitrage/resource-state-config.html>`_
* `Alarm State Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/alarm-state-config.rst>`_ * `Alarm Severity Configuration <http://docs.openstack.org/developer/vitrage/alarm-severity-config.html>`_
* `Zabbix Configuration <https://github.com/openstack/vitrage/blob/master/doc/source/zabbix_vitrage.rst>`_ * `Zabbix Configuration <http://docs.openstack.org/developer/vitrage/zabbix_vitrage.html>`_

23
doc/source/nagios-config.rst
View File

@ -5,7 +5,7 @@ Nagios Plugin Configuration
Configure Access to Nagios Configure Access to Nagios
-------------------------- --------------------------
The following should be set in **/etc/vitrage/vitrage.conf**, under [nagios] section: The following should be set in ``/etc/vitrage/vitrage.conf``, under ``[nagios]`` section:
+------------------+---------------------------------------------------------+-------------------------------+ +------------------+---------------------------------------------------------+-------------------------------+
| Name | Description | Default Value | | Name | Description | Default Value |
@ -31,9 +31,9 @@ Nagios access configuration - example
When installing Nagios on devstack with IP 10.20.30.40, following When installing Nagios on devstack with IP 10.20.30.40, following
the instructions here_, this would be the correct configuration: the instructions here_, this would be the correct configuration:
.. _here: https://github.com/openstack/vitrage/blob/master/doc/source/nagios-devstack-installation.rst .. _here: nagios-devstack-installation.html
:: .. code::
[nagios] [nagios]
user = omdadmin user = omdadmin
@ -54,7 +54,7 @@ to map each Nagios host to a Vitrage resource.
Format Format
++++++ ++++++
:: .. code ::
nagios: nagios:
- nagios_host: <Host as appears in Nagios> - nagios_host: <Host as appears in Nagios>
@ -64,7 +64,6 @@ Format
- nagios_host: <Host as appears in Nagios> - nagios_host: <Host as appears in Nagios>
type: <resource type in Vitrage> type: <resource type in Vitrage>
name: <resource name in Vitrage> name: <resource name in Vitrage>
... ...
Note that for ease of use, there is support for wildcards in the "nagios_host" Note that for ease of use, there is support for wildcards in the "nagios_host"
@ -79,7 +78,7 @@ Example 1
The following example is for a system with two hosts. In nagios they are named The following example is for a system with two hosts. In nagios they are named
*compute-0, compute-1*, and in nova they are named *host-1, host-2*. *compute-0, compute-1*, and in nova they are named *host-1, host-2*.
:: .. code::
nagios: nagios:
- nagios_host: compute-0 - nagios_host: compute-0
@ -94,15 +93,15 @@ Example 2
+++++++++ +++++++++
The following file will The following file will
- map all Nagios hosts named host-*<some_suffix>* or *<some_prefix>*-devstack - map all Nagios hosts named ``host-<some_suffix>`` or ``<some_prefix>-devstack``
to resources of type nova.host with the same name. to resources of type ``nova.host`` with the same name.
- map all Nagios hosts named instance-*<some_suffix>* to nova.instance - map all Nagios hosts named ``instance-<some_suffix>`` to ``nova.instance``
resources. resources.
Note how the *${nagios_host}* references the instantiation of the regex defined Note how the ``${nagios_host}`` references the instantiation of the regex defined
in nagios_host. in ``nagios_host``.
:: .. code::
nagios: nagios:
- nagios_host: host-(.*) - nagios_host: host-(.*)

31
doc/source/nagios-devstack-installation.rst
View File

@ -25,12 +25,14 @@ Installation
------------ ------------
1. Update your repo to include the OMD key: 1. Update your repo to include the OMD key:
::
.. code::
wget -q "https://labs.consol.de/repo/stable/RPM-GPG-KEY" -O - | sudo apt-key add - wget -q "https://labs.consol.de/repo/stable/RPM-GPG-KEY" -O - | sudo apt-key add -
2. Update your repo with the OMD site. For example, for ubuntu trusty release: 2. Update your repo with the OMD site. For example, for ubuntu trusty release:
::
.. code::
sudo bash -c "echo 'deb https://labs.consol.de/repo/stable/ubuntu trusty main' >> /etc/apt/sources.list" sudo bash -c "echo 'deb https://labs.consol.de/repo/stable/ubuntu trusty main' >> /etc/apt/sources.list"
sudo apt-get update sudo apt-get update
@ -38,21 +40,24 @@ Installation
For additional distros, see https://labs.consol.de/repo/stable/ For additional distros, see https://labs.consol.de/repo/stable/
3. Install OMD 3. Install OMD
::
.. code::
sudo apt-get install omd sudo apt-get install omd
4. Create a site for nagios with a name of your choosing, for example 4. Create a site for nagios with a name of your choosing, for example
"my_site". ``my_site``.
::
.. code::
sudo omd create my_site sudo omd create my_site
sudo omd config my_site set APACHE_TCP_PORT 54321 sudo omd config my_site set APACHE_TCP_PORT 54321
sudo omd config my_site set APACHE_TCP_ADDR 0.0.0.0 sudo omd config my_site set APACHE_TCP_ADDR 0.0.0.0
sudo omd start my_site sudo omd start my_site
You can now access your Nagios site here: *http://<devstack_ip>:54321/my_site/omd*. You can now access your Nagios site here: *http://<devstack_ip>:54321/my_site/omd/*.
::
.. code::
username: omdadmin username: omdadmin
password: omd password: omd
@ -67,17 +72,19 @@ Installation
- When using devstack, remember to stop omd apache2's sites - When using devstack, remember to stop omd apache2's sites
5. Install the Check_MK agent on devstack VM: 5. Install the Check_MK agent on devstack VM:
::
.. code::
sudo apt-get install check-mk-agent sudo apt-get install check-mk-agent
6. Activate the Check_MK agent, by editing */etc/xinetd.d/check_mk* and 6. Activate the Check_MK agent, by editing ``/etc/xinetd.d/check_mk`` and
**setting "disable" to "no"**, and then run **setting "disable" to "no"**, and then run
::
.. code::
sudo service xinetd restart sudo service xinetd restart
7. In your browser, go to *http://<devstack_ip>:<selected port>/my_site/omd* 7. In your browser, go to *http://<devstack_ip>:<selected port>/my_site/omd/*
and follow the instructions at this link_ (**"Configuring the first host and and follow the instructions at this link_ (**"Configuring the first host and
checks"** section) to configure the nagios host. checks"** section) to configure the nagios host.
@ -86,4 +93,4 @@ Installation
8. *Vitrage Support.* With Nagios installed, you can now configure a datasource 8. *Vitrage Support.* With Nagios installed, you can now configure a datasource
for it for Vitrage, by following the instructions here_. for it for Vitrage, by following the instructions here_.
.. _here: https://github.com/openstack/vitrage/blob/master/doc/source/nagios-config.rst .. _here: nagios-config.html

25
doc/source/notifier-aodh-plugin.rst
View File

@ -5,6 +5,7 @@ Vitrage Notifier plugins - AODH
Overview Overview
======== ========
The Evaluator performs root cause analysis on the Vitrage Graph and may determine that an alarm should be created, deleted or otherwise updated. The Evaluator performs root cause analysis on the Vitrage Graph and may determine that an alarm should be created, deleted or otherwise updated.
Other components are notified of such changes by the Vitrage Notifier service. Among others, Vitrage Notifier is responsible for handling Aodh Alarms. Other components are notified of such changes by the Vitrage Notifier service. Among others, Vitrage Notifier is responsible for handling Aodh Alarms.
This document describes the implementation of Vitrage Notifier infrastructure and specifically notifying Aodh on Vitrage alarms. This document describes the implementation of Vitrage Notifier infrastructure and specifically notifying Aodh on Vitrage alarms.
@ -49,15 +50,15 @@ Deduced Alarms bus notifications
Vitrage Evaluator will create a deduced alarm, sending it to the data source queue Vitrage Evaluator will create a deduced alarm, sending it to the data source queue
Vitrage Evaluator will use the **vitrage.graph** message bus topic, and will post messages as follows: Vitrage Evaluator will use the **vitrage.graph** message bus topic, and will post messages as follows:
- message of type **vitrage.deduced_alarm.activate** : - message of type ``vitrage.deduced_alarm.activate`` :
* name - is the alarm name in vitrage * ``name`` - is the alarm name in vitrage
* severity - is the alarm severity * ``severity`` - is the alarm severity
* affected_resource_id - is the openstack id of the resource on which the alarm was raised * ``affected_resource_id`` - is the openstack id of the resource on which the alarm was raised
- **vitrage.deduced_alarm.deactivate** - ``vitrage.deduced_alarm.deactivate``
* id - is the alarm id * ``id`` - is the alarm id
Notifier Notifier
======== ========
@ -71,9 +72,9 @@ Aodh Plugin
=========== ===========
Vitrage alarms should be reflected as possible in Aodh. The aodh plugin has ceilometer client by which it can send rest calls to aodh Vitrage alarms should be reflected as possible in Aodh. The aodh plugin has ceilometer client by which it can send rest calls to aodh
Handle vitrage.deduced_alarm.activate: Handle ``vitrage.deduced_alarm.activate``
------------------------------------- -----------------------------------------
Create an event alarm with the specified severity, where the alarm name is vitrage_alarm_name+resource_id so to be unique Create an event alarm with the specified severity, where the alarm name is ``vitrage_alarm_name+resource_id`` so to be unique
- Message does not contain aodh alarm id: - Message does not contain aodh alarm id:
@ -86,8 +87,8 @@ Create an event alarm with the specified severity, where the alarm name is vitra
* plugin will **update** the aodh alarm status to alarm * plugin will **update** the aodh alarm status to alarm
Handle vitrage.deduced_alarm.deactivate: Handle ``vitrage.deduced_alarm.deactivate``
--------------------------------------- -------------------------------------------
delete an event alarm with the specified id Delete an event alarm with the specified id
* message will contain the aodh alarm id - plugin will **update** the alarm status to ok * message will contain the aodh alarm id - plugin will **update** the alarm status to ok

35
doc/source/resource-state-config.rst
View File

@ -25,7 +25,7 @@ Configure Access to Resource State
---------------------------------- ----------------------------------
The resource state configuration is handled via config files. The location of The resource state configuration is handled via config files. The location of
these files can be determined in **/etc/vitrage/vitrage.conf**. Under the these files can be determined in ``/etc/vitrage/vitrage.conf``. Under the
[entity_graph] section, set: [entity_graph] section, set:
+------------------------+------------------------------------+----------------------------------+ +------------------------+------------------------------------+----------------------------------+
@ -65,27 +65,22 @@ Default Configuration
Default configurations for resource states will be installed with Vitrage for Default configurations for resource states will be installed with Vitrage for
all the pre-packaged data-sources. all the pre-packaged data-sources.
Format Format
++++++ ++++++
::
category: RESOURCE
values:
- aggregated values:
priority: <Resource state priority - an integer>
original values:
- name: <Original resource state name>
operational_value: <normalized resource state - from
OperationalResourceState class>
- name: ... # can list several states for one aggregation
- aggregated values:
priority: ... # can list several aggregated states
...
.. code:: yaml
category: RESOURCE
values:
- aggregated values:
priority: <Resource state priority - an integer>
original values:
- name: <Original resource state name>
operational_value: <normalized resource state - from OperationalResourceState class>
- name: ... # can list several states for one aggregation
- aggregated values:
priority: ... # can list several aggregated states
...
... ...
@ -93,12 +88,14 @@ Example
+++++++ +++++++
The following file will map resource states. The following file will map resource states.
For aggregated state with priority 40 we have 4 states and each one of them is For aggregated state with priority 40 we have 4 states and each one of them is
mapped to operational severity ERROR. mapped to operational severity ERROR.
For aggregated state with priority 30 we have 6 states and each one of them is For aggregated state with priority 30 we have 6 states and each one of them is
mapped to operational severity TRANSIENT, etc... mapped to operational severity TRANSIENT, etc...
:: .. code :: yaml
category: RESOURCE category: RESOURCE
values: values:

2
doc/source/scenario-evaluator.rst
View File

@ -88,7 +88,7 @@ Template Loading
Scenarios are written up in configuration files called *templates*. The format Scenarios are written up in configuration files called *templates*. The format
and specification of these can be seen here_. and specification of these can be seen here_.
.. _here: https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst .. _here: vitrage-template-format.html
Templates should all be located in the *<vitrage folder>/templates* folder. Templates should all be located in the *<vitrage folder>/templates* folder.

71
doc/source/static-physical-config.rst
View File

@ -9,13 +9,13 @@ The Static Physical datasource allows users to integrate the physical topology
into Vitrage. Physical topology includes switches and their connection to into Vitrage. Physical topology includes switches and their connection to
other switches and physical hosts. other switches and physical hosts.
This datasource is static - pre-configured in a file. This is sufficient in This datasource is static - pre-configured in a file. This is sufficient in
many cases where the physical topology is relatively unchanging. many cases where the physical topology is relatively unchanging.
Configure Access to Static Physical Configure Access to Static Physical
----------------------------------- -----------------------------------
The following should be set in **/etc/vitrage/vitrage.conf**, under The following should be set in **/etc/vitrage/vitrage.conf**, under
[static_physical] section: [static_physical] section:
+------------------+---------------------------------------------------------+----------------------------------+ +------------------+---------------------------------------------------------+----------------------------------+
@ -32,41 +32,40 @@ The following should be set in **/etc/vitrage/vitrage.conf**, under
Configure Static Physical Mapping Configure Static Physical Mapping
--------------------------------- ---------------------------------
Physical configuration is made for configuring statically physical entities, Physical configuration is made for configuring statically physical entities,
and their relationships to other entities in the topology. and their relationships to other entities in the topology.
Some physical entities, such as switches, can not be retrieved from OpenStack, Some physical entities, such as switches, can not be retrieved from OpenStack,
and so are defined here. and so are defined here.
There may be more than one configuration file. All files will be read from There may be more than one configuration file. All files will be read from
*/etc/vitrage/static_datasources/*. See previous section on how to configure this */etc/vitrage/static_datasources/*. See previous section on how to configure this
location. location.
Format Format
++++++ ++++++
:: .. code::
entities:
- name: <Physical entity name as appears in configuration>
id: <Physical entity id as appears in configuration>
type: <Physical entity type - see below for details>
state: <default resource state>
relationships:
- type: <Physical entity type it is connected to - see below for details>
name: <Name of physical entity as appears in configuration>
id: <Id of physical entity as appears in configuration>
relation_type: <Relation name>
- type: ...
entities:
- name: <Physical entity name as appears in configuration>
id: <Physical entity id as appears in configuration>
type: <Physical entity type - see below for details>
state: <default resource state>
relationships:
- type: <Physical entity type it is connected to - see below for details>
name: <Name of physical entity as appears in configuration>
id: <Id of physical entity as appears in configuration>
relation_type: <Relation name>
- type: ...
... ...
Notes: Notes:
- The "type" key must match the name of a type from an existing datasource. - The "type" key must match the name of a type from an existing datasource.
Type names appear, for each datasource, in its __init__.py file. For example - Type names appear, for each datasource, in its __init__.py file.
see */workspace/dev/vitrage/vitrage/datasources/nova/host/__init__.py* - For example see */workspace/dev/vitrage/vitrage/datasources/nova/host/__init__.py*
Example Example
+++++++ +++++++
@ -74,20 +73,20 @@ Example
The following will define a switch that is attached to host-1 and is a backup The following will define a switch that is attached to host-1 and is a backup
of switch-2 of switch-2
:: .. code::
entities: entities:
- type: switch - type: switch
name: switch-1 name: switch-1
id: switch-1 # should be same as name id: switch-1 # should be same as name
state: available state: available
relationships: relationships:
- type: nova.host - type: nova.host
name: host-1 name: host-1
id: host-1 # should be same as name id: host-1 # should be same as name
relation_type: attached relation_type: attached
- type: switch - type: switch
name: switch-2 name: switch-2
id: switch-2 # should be same as name id: switch-2 # should be same as name
relation_type: backup relation_type: backup

18
doc/source/vitrage-first_steps.rst
View File

@ -11,9 +11,9 @@ Before you start
Installation Installation
============ ============
- `Enable Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst/>`_ - `Enable Vitrage in devstack <https://github.com/openstack/vitrage/blob/master/devstack/README.rst>`_
- `Enable Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst/>`_ - `Enable Vitrage in horizon <https://github.com/openstack/vitrage-dashboard/blob/master/README.rst>`_
- run ./stack.sh - run ``./stack.sh``
Nagios Installation & Configuration Nagios Installation & Configuration
@ -27,8 +27,8 @@ as the trigger for deduced alarms, states and RCA templates in Vitrage.
.. _Nagios: https://www.nagios.org/ .. _Nagios: https://www.nagios.org/
- `Install Nagios on your devstack <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-devstack-installation.rst/>`_ - `Install Nagios on your devstack <http://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html>`_
- `Configure Nagios datasource <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-config.rst>`_ - `Configure Nagios datasource <http://docs.openstack.org/developer/vitrage/nagios-config.html>`_
Vitrage in action Vitrage in action
@ -37,7 +37,7 @@ Vitrage in action
In order to see Vitrage in action, you should place your templates under In order to see Vitrage in action, you should place your templates under
*/etc/vitrage/templates*. See template_ example. */etc/vitrage/templates*. See template_ example.
.. _template: https://github.com/openstack/vitrage/blob/master/doc/source/host_high_memory_consumption.yaml .. _template: host_high_memory_consumption.yaml
In the example shown here, we will cause Nagios to report high memory usage on In the example shown here, we will cause Nagios to report high memory usage on
the devstack host. As a result and as defined in our sample template, Vitrage the devstack host. As a result and as defined in our sample template, Vitrage
@ -114,12 +114,12 @@ differently, for each data-source you can define it's own mapping to the
*normalized* states/severities supported in Vitrage. This will impact UI and *normalized* states/severities supported in Vitrage. This will impact UI and
templates behavior that depends on these fields. templates behavior that depends on these fields.
- `Resource state configuration <https://github.com/openstack/vitrage/blob/master/doc/source/resource-state-config.rst/>`_ - `Resource state configuration <http://docs.openstack.org/developer/vitrage/resource-state-config.html>`_
- `Alarm severity configuration <https://github.com/openstack/vitrage/blob/master/doc/source/alarm-state-config.rst/>`_ - `Alarm severity configuration <http://docs.openstack.org/developer/vitrage/alarm-severity-config.html>`_
Writing your own templates Writing your own templates
-------------------------- --------------------------
For more information regarding Vitrage templates, their format and how to add For more information regarding Vitrage templates, their format and how to add
them, see here_. them, see here_.
.. _here: https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst .. _here: http://docs.openstack.org/developer/vitrage/vitrage-template-format.html

56
doc/source/zabbix_vitrage.rst
View File

@ -7,9 +7,9 @@ Consolidate Zabbix alerts from across multiple sites into a single "at-a-glance"
Installation Installation
------------ ------------
**Note:** Don't try to use zabbix with docker image to test, because `zabbix_vitrage.py` require some openstack libraries (`oslo.messaging` and `oslo.config`). **Note:** Don't try to use zabbix with docker image to test, because ``zabbix_vitrage.py`` requires some openstack libraries (``oslo.messaging`` and ``oslo.config``).
Copy the `zabbix_vitrage.py` script into the Zabbix servers' `AlertScriptsPath` directory which is by default `/usr/lib/zabbix/alertscripts` and make it executable: Copy the ``zabbix_vitrage.py`` script into the Zabbix servers' ``AlertScriptsPath`` directory which is by default ``/usr/lib/zabbix/alertscripts`` and make it executable:
.. code-block:: bash .. code-block:: bash
@ -17,7 +17,7 @@ Copy the `zabbix_vitrage.py` script into the Zabbix servers' `AlertScriptsPath`
$ cp zabbix_vitrage.py /usr/lib/zabbix/alertscripts/ $ cp zabbix_vitrage.py /usr/lib/zabbix/alertscripts/
$ chmod 755 /usr/lib/zabbix/alertscripts/zabbix_vitrage.py $ chmod 755 /usr/lib/zabbix/alertscripts/zabbix_vitrage.py
Install `oslo.messaging` and `oslo.config` to zabbix host (may require root): Install ``oslo.messaging`` and ``oslo.config`` to zabbix host (may require root):
.. code:: bash .. code:: bash
@ -30,35 +30,35 @@ To forward zabbix events to Vitrage a new media script needs to be created and a
1. Create a new media type [Admininstration > Media Types > Create Media Type] 1. Create a new media type [Admininstration > Media Types > Create Media Type]
| Name: Vitrage Notifications | **Name:** Vitrage Notifications
| Type: Script | **Type:** Script
| Script name: zabbix_vitrage.py | **Script name:** zabbix_vitrage.py
| Script parameters: | **Script parameters**:
| 1st line: {ALERT.SENDTO} | **1st line:** {ALERT.SENDTO}
| 2nd line: {ALERT.SUBJECT} | **2nd line:** {ALERT.SUBJECT}
| 3rd line: {ALERT.MESSAGE} | **3rd line:** {ALERT.MESSAGE}
2. Modify the Media for the Admin user [Administration > Users] 2. Modify the Media for the Admin user [Administration > Users]
| Type: vitrage Notifications | **Type:** Vitrage Notifications
| Send to: rabbit://rabbit_user:rabbit_pass@127.0.0.1:5672/ <--- Vitrage message bus url | **Send to:** ``rabbit://rabbit_user:rabbit_pass@127.0.0.1:5672/`` <--- Vitrage message bus url
| When active: 1-7,00:00-24:00 | **When active:** 1-7,00:00-24:00
| Use if severity: tick all options | **Use if severity:** tick all options
| Status: Enabled | **Status:** Enabled
**Note:** Default rabbit_user/rabbit_pass for devstack rabbitmq is `stackrabbit/secret` **Note:** Default ``rabbit_user/rabbit_pass`` for devstack rabbitmq is ``stackrabbit/secret``
3. Configure Action [Configuration > Actions > Create Action > Action] 3. Configure Action [Configuration > Actions > Create Action > Action]
| Name: Forward to Vitrage | **Name:** Forward to Vitrage
| Default Subject: {TRIGGER.STATUS} | **Default Subject:** {TRIGGER.STATUS}
| Add an operation: | **Add an operation:**
| Send to Users: Admin | **Send to Users:** Admin
| Send only to: Vitrage Notifications | **Send only to:** Vitrage Notifications
| Default Message: | **Default Message:**
| host={HOST.NAME1} | host={HOST.NAME1}
| hostid={HOST.ID1} | hostid={HOST.ID1}
| hostip={HOST.IP1} | hostip={HOST.IP1}
@ -70,35 +70,35 @@ To forward zabbix events to Vitrage a new media script needs to be created and a
| priority={TRIGGER.NSEVERITY} | priority={TRIGGER.NSEVERITY}
| lastchange={EVENT.DATE} {EVENT.TIME} | lastchange={EVENT.DATE} {EVENT.TIME}
| To send events add under the Conditions tab: | **To send events add under the Conditions tab:**
| (A) Maintenance status not in `maintenance` | (A) Maintenance status not in `maintenance`
For a full list of trigger macros see https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location For a full list of trigger macros see https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location
To test zabbix events and vitrage alarms, please see zabbix trgger documentation: https://www.zabbix.com/documentation/3.2/manual/config/triggers/trigger To test zabbix events and vitrage alarms, please see zabbix trigger documentation: https://www.zabbix.com/documentation/3.2/manual/config/triggers/trigger
Vitrage configuration Vitrage configuration
--------------------- ---------------------
1. Add zabbix to list of datasources in /etc/vitrage/vitrage.conf 1. Add zabbix to list of datasources in ``/etc/vitrage/vitrage.conf``
.. code:: .. code::
[datasources] [datasources]
types = zabbix,nova.host,nova.instance,nova.zone,static_physical,aodh,cinder.volume,neutron.network,neutron.port,heat.stack types = zabbix,nova.host,nova.instance,nova.zone,static_physical,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
2. Add following section to /etc/vitrage/vitrage.conf 2. Add following section to ``/etc/vitrage/vitrage.conf``
.. code:: .. code::
[zabbix] [zabbix]
url = http://135.248.18.30 # URL to zabbix url = http://<ip>/zabbix # URL to zabbix
password = zabbix password = zabbix
user = admin user = admin
config_file = /etc/vitrage/zabbix_conf.yaml config_file = /etc/vitrage/zabbix_conf.yaml
2. Create /etc/vitrage/zabbix_conf.yaml with this content 2. Create ``/etc/vitrage/zabbix_conf.yaml`` with this content
.. code :: .. code ::