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
----------------------------
see `README file <https://github.com/openstack/vitrage/blob/master/devstack/README.rst/>`_
More details in: `README file <devstack/README.rst>`_
Project Resources
-----------------
* wiki page: https://wiki.openstack.org/wiki/Vitrage
* Wiki page: https://wiki.openstack.org/wiki/Vitrage
* Launchpad: https://launchpad.net/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
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
and your datasources' transformer class. See below for details on those
classes.
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
your needed options using the oslo_config.cfg module.
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
your needed options using the ``oslo_config.cfg`` module.
There are three options you must have:
a. Driver and transformer with the path to your driver and transformer
classes respectively.
b. update_method property that describes the type of update mechanism for
this datasource. The options are: push, pull or none.
b. ``update_method`` property that describes the type of update mechanism for
this datasource. The options are (string): push, pull or none.
c. In addition to those three, you may add any other configuration options
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
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.
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>
datasource not installed
.. code:: bash
if ! is_service_enabled <datasource_name>; then
# remove <datasource_name> vitrage datasource if <datasource_name> datasource not installed
disable_vitrage_datasource <datasource_name>
fi
if ! is_service_enabled <datasource_name>; then
disable_vitrage_datasource <datasource_name>
fi
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.)
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.
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).
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:
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.
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
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:
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.
A transformer should inherit from
'vitrage.datasoures.transformer_base.TransformerBase' class and
``vitrage.datasoures.transformer_base.TransformerBase`` class and
must implement the following methods:
+----------------------------------+------------------------------------+----------------------------------------+
@ -138,7 +137,7 @@ Holds the following fields:
**Example**
Datasource __init__.py OPTS:
Datasource ``__init__.py OPTS``:
.. code:: python
@ -168,23 +167,25 @@ Datasource __init__.py OPTS:
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
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
datasources' OPTS an Integer option named 'changes_interval'.
Additionally, vitrage.entity_graph.transformer_manager.TransformerManager
datasources ``OPTS`` an ``Integer`` option named ``changes_interval``.
Additionally, ``vitrage.entity_graph.transformer_manager.TransformerManager``
will get instantiated and will register all of the datasources transformers
into Vitrage.
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
--------------------------------
Any option your datasource defined can be accessed using oslo_config.cfg
or by configuring vitrage.conf.
Any option your datasource defined can be accessed using ``oslo_config.cfg``
or by configuring ``vitrage.conf``.
**Example**
@ -195,26 +196,23 @@ or by configuring vitrage.conf.
**Example**
/etc/vitrage/vitrage.conf
.. code::
# /etc/vitrage/vitrage.conf
...
[datasources]
snapshots_interval = 300
# Names of supported plugins (list value)
types = nova.host,nova.instance,nova.zone,static_physical,nagios,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
types = nagios,zabbix,nova.host,nova.instance,nova.zone,static_physical,aodh,cinder.volume,neutron.network,neutron.port,heat.stack
[zabbix]
url = http://135.248.18.30
url = http://<ip>/zabbix
password = zabbix
user = admin
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
in Vitrage. This way we can know which severity is more important.
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.
This page explains how to handle this mapping for a given
data-source.
@ -66,12 +67,10 @@ Default Configuration
Default configurations for alarms severities will be installed with Vitrage for
all the pre-packaged data-sources.
Format
++++++
::
.. code:: yaml
category: ALARM
values:
@ -79,13 +78,11 @@ Format
priority: <Alarm severity priority - an integer>
original values:
- name: <Original alarm severity name>
operational_value: <normalized alarm severity - from
OperationalAlarmSeverity class>
operational_value: <normalized alarm severity - from OperationalAlarmSeverity class>
- name: ... # can list several severities for one aggregation
- aggregated values:
priority: ... # can list several aggregated severities
...
...
@ -93,11 +90,14 @@ Example
+++++++
The following file will map alarm severities.
For aggregated severity with priority 40 we have 2 severities and each one of
them is mapped to operational severity CRITICAL.
For aggregated severity with priority 30 we have 1 severity called WARNING and
it is mapped to operational severity WARNING, etc...
::
.. code:: yaml
category: ALARM
values:

2
doc/source/conf.py
View File

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

4
doc/source/index.rst
View File

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

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

@ -2,26 +2,30 @@
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
-------------
* `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
--------------------------
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 |
@ -31,9 +31,9 @@ Nagios access configuration - example
When installing Nagios on devstack with IP 10.20.30.40, following
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]
user = omdadmin
@ -54,7 +54,7 @@ to map each Nagios host to a Vitrage resource.
Format
++++++
::
.. code ::
nagios:
- nagios_host: <Host as appears in Nagios>
@ -64,7 +64,6 @@ Format
- nagios_host: <Host as appears in Nagios>
type: <resource type in Vitrage>
name: <resource name in Vitrage>
...
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
*compute-0, compute-1*, and in nova they are named *host-1, host-2*.
::
.. code::
nagios:
- nagios_host: compute-0
@ -94,15 +93,15 @@ Example 2
+++++++++
The following file will
- map all Nagios hosts named host-*<some_suffix>* or *<some_prefix>*-devstack
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 ``host-<some_suffix>`` or ``<some_prefix>-devstack``
to resources of type ``nova.host`` with the same name.
- map all Nagios hosts named ``instance-<some_suffix>`` to ``nova.instance``
resources.
Note how the *${nagios_host}* references the instantiation of the regex defined
in nagios_host.
Note how the ``${nagios_host}`` references the instantiation of the regex defined
in ``nagios_host``.
::
.. code::
nagios:
- 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:
::
.. code::
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:
::
.. code::
sudo bash -c "echo 'deb https://labs.consol.de/repo/stable/ubuntu trusty main' >> /etc/apt/sources.list"
sudo apt-get update
@ -38,21 +40,24 @@ Installation
For additional distros, see https://labs.consol.de/repo/stable/
3. Install OMD
::
.. code::
sudo apt-get install omd
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 config my_site set APACHE_TCP_PORT 54321
sudo omd config my_site set APACHE_TCP_ADDR 0.0.0.0
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
password: omd
@ -67,17 +72,19 @@ Installation
- When using devstack, remember to stop omd apache2's sites
5. Install the Check_MK agent on devstack VM:
::
.. code::
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
::
.. code::
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
checks"** section) to configure the nagios host.
@ -86,4 +93,4 @@ Installation
8. *Vitrage Support.* With Nagios installed, you can now configure a datasource
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
========
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.
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 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
* severity - is the alarm severity
* affected_resource_id - is the openstack id of the resource on which the alarm was raised
* ``name`` - is the alarm name in vitrage
* ``severity`` - is the alarm severity
* ``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
========
@ -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
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
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
- 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
Handle vitrage.deduced_alarm.deactivate:
---------------------------------------
delete an event alarm with the specified id
Handle ``vitrage.deduced_alarm.deactivate``
-------------------------------------------
Delete an event alarm with the specified id
* 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
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:
+------------------------+------------------------------------+----------------------------------+
@ -65,27 +65,22 @@ Default Configuration
Default configurations for resource states will be installed with Vitrage for
all the pre-packaged data-sources.
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.
For aggregated state with priority 40 we have 4 states and each one of them is
mapped to operational severity ERROR.
For aggregated state with priority 30 we have 6 states and each one of them is
mapped to operational severity TRANSIENT, etc...
::
.. code :: yaml
category: RESOURCE
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
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.

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
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.
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:
+------------------+---------------------------------------------------------+----------------------------------+
@ -32,41 +32,40 @@ The following should be set in **/etc/vitrage/vitrage.conf**, under
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.
Some physical entities, such as switches, can not be retrieved from OpenStack,
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
location.
Format
++++++
::
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: ...
.. 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: ...
...
Notes:
- 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
see */workspace/dev/vitrage/vitrage/datasources/nova/host/__init__.py*
- 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 see */workspace/dev/vitrage/vitrage/datasources/nova/host/__init__.py*
Example
+++++++
@ -74,20 +73,20 @@ Example
The following will define a switch that is attached to host-1 and is a backup
of switch-2
::
.. code::
entities:
- type: switch
name: switch-1
id: switch-1 # should be same as name
state: available
relationships:
- type: nova.host
name: host-1
id: host-1 # should be same as name
relation_type: attached
- type: switch
name: switch-2
id: switch-2 # should be same as name
relation_type: backup
entities:
- type: switch
name: switch-1
id: switch-1 # should be same as name
state: available
relationships:
- type: nova.host
name: host-1
id: host-1 # should be same as name
relation_type: attached
- type: switch
name: switch-2
id: switch-2 # should be same as name
relation_type: backup

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

@ -11,9 +11,9 @@ Before you start
Installation
============
- `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/>`_
- run ./stack.sh
- `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>`_
- run ``./stack.sh``
Nagios Installation & Configuration
@ -27,8 +27,8 @@ as the trigger for deduced alarms, states and RCA templates in Vitrage.
.. _Nagios: https://www.nagios.org/
- `Install Nagios on your devstack <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-devstack-installation.rst/>`_
- `Configure Nagios datasource <https://github.com/openstack/vitrage/blob/master/doc/source/nagios-config.rst>`_
- `Install Nagios on your devstack <http://docs.openstack.org/developer/vitrage/nagios-devstack-installation.html>`_
- `Configure Nagios datasource <http://docs.openstack.org/developer/vitrage/nagios-config.html>`_
Vitrage in action
@ -37,7 +37,7 @@ Vitrage in action
In order to see Vitrage in action, you should place your templates under
*/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
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
templates behavior that depends on these fields.
- `Resource state configuration <https://github.com/openstack/vitrage/blob/master/doc/source/resource-state-config.rst/>`_
- `Alarm severity configuration <https://github.com/openstack/vitrage/blob/master/doc/source/alarm-state-config.rst/>`_
- `Resource state configuration <http://docs.openstack.org/developer/vitrage/resource-state-config.html>`_
- `Alarm severity configuration <http://docs.openstack.org/developer/vitrage/alarm-severity-config.html>`_
Writing your own templates
--------------------------
For more information regarding Vitrage templates, their format and how to add
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
------------
**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
@ -17,7 +17,7 @@ Copy the `zabbix_vitrage.py` script into the Zabbix servers' `AlertScriptsPath`
$ cp zabbix_vitrage.py /usr/lib/zabbix/alertscripts/
$ 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
@ -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]
| Name: Vitrage Notifications
| Type: Script
| Script name: zabbix_vitrage.py
| Script parameters:
| 1st line: {ALERT.SENDTO}
| 2nd line: {ALERT.SUBJECT}
| 3rd line: {ALERT.MESSAGE}
| **Name:** Vitrage Notifications
| **Type:** Script
| **Script name:** zabbix_vitrage.py
| **Script parameters**:
| **1st line:** {ALERT.SENDTO}
| **2nd line:** {ALERT.SUBJECT}
| **3rd line:** {ALERT.MESSAGE}
2. Modify the Media for the Admin user [Administration > Users]
| Type: vitrage Notifications
| Send to: rabbit://rabbit_user:rabbit_pass@127.0.0.1:5672/ <--- Vitrage message bus url
| When active: 1-7,00:00-24:00
| Use if severity: tick all options
| Status: Enabled
| **Type:** Vitrage Notifications
| **Send to:** ``rabbit://rabbit_user:rabbit_pass@127.0.0.1:5672/`` <--- Vitrage message bus url
| **When active:** 1-7,00:00-24:00
| **Use if severity:** tick all options
| **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]
| Name: Forward to Vitrage
| Default Subject: {TRIGGER.STATUS}
| **Name:** Forward to Vitrage
| **Default Subject:** {TRIGGER.STATUS}
| Add an operation:
| Send to Users: Admin
| Send only to: Vitrage Notifications
| **Add an operation:**
| **Send to Users:** Admin
| **Send only to:** Vitrage Notifications
| Default Message:
| **Default Message:**
| host={HOST.NAME1}
| hostid={HOST.ID1}
| 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}
| 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`
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
---------------------
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::
[datasources]
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::
[zabbix]
url = http://135.248.18.30 # URL to zabbix
url = http://<ip>/zabbix # URL to zabbix
password = zabbix
user = admin
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 ::