Beautify, correct URLs in documentation files
- Beautify, re-indent, format code in a lot of doc files
- Use relative URLs instead of absolute github URLs
- Some absolute github urls are not corrected yet:
+ URL for enabling vitrage in devstack
+ URL for enabling vitrage in horizon
- Update year number in doc/source/config.py from 2013 to 2016
My thought: We should have a blueprint
to create more concise and easy to access like other project
(nova: http://docs.openstack.org/developer/nova/).
Currently, that site for vitrage has not existed yet.
Notes: Change github URLs to relative URLs
(or absolute URLs in docs.openstack.org/developers)
will not work correctly
if we do not have official documentation site.
Hence, other people cannot follow the link to html page
if they read vitrage documentation in github mirror.
Change-Id: Ifff8355c7e5291f68a7592d1617644053d790d5e
This commit is contained in:
Tovin Seven
parent
e070c4a135
commit
e2b21d516d
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>`_
|
||||
|
||||
|
||||
@ -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-(.*)
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 ::
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user