diff --git a/README.rst b/README.rst index a1804c0a0..ed7845998 100644 --- a/README.rst +++ b/README.rst @@ -8,12 +8,12 @@ Vitrage is the OpenStack RCA (Root Cause Analysis) Service for organizing, analy Enabling Vitrage in DevStack ---------------------------- -see `README file `_ +More details in: `README file `_ 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 diff --git a/doc/source/add-new-datasource.rst b/doc/source/add-new-datasource.rst index dddb67386..2bff48b79 100644 --- a/doc/source/add-new-datasource.rst +++ b/doc/source/add-new-datasource.rst @@ -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 vitrage datasource if - datasource not installed + .. code:: bash - if ! is_service_enabled ; then + # remove vitrage datasource if datasource not installed - disable_vitrage_datasource - - fi + if ! is_service_enabled ; then + disable_vitrage_datasource + 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 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:///zabbix password = zabbix - user = admin - config_file = /etc/vitrage/zabbix_conf.yaml + [nagios] + user = omdadmin + password = omd + url = http://://nagios/cgi-bin/status.cgi + config_file = /etc/vitrage/nagios_conf.yaml diff --git a/doc/source/alarm-severity-config.rst b/doc/source/alarm-severity-config.rst index cec5497c9..d531f1f97 100644 --- a/doc/source/alarm-severity-config.rst +++ b/doc/source/alarm-severity-config.rst @@ -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: original values: - name: - operational_value: + operational_value: - 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: diff --git a/doc/source/conf.py b/doc/source/conf.py index 4ebfa14e4..35cdaee29 100755 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -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 diff --git a/doc/source/index.rst b/doc/source/index.rst index b8d1ae86a..b0e42899a 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -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 diff --git a/doc/source/installation-and-configuration.rst b/doc/source/installation-and-configuration.rst index 529cea68a..ce2b6d869 100644 --- a/doc/source/installation-and-configuration.rst +++ b/doc/source/installation-and-configuration.rst @@ -2,26 +2,30 @@ Installation ============ -In order to enable Vitrage: +------------------------------- +Enable Vitrage and data sources +------------------------------- -* `Enabling Vitrage in devstack `_ +* `Enabling Vitrage in devstack `_ -* `Enabling Vitrage in horizon `_ +* `Enabling Vitrage in horizon `_ -* `Nagios devstack installation `_ +* `Nagios devstack installation `_ + +* `Zabbix devstack installation `_ ------------- Configuration ------------- -* `Nagios Plugin Configuration `_ +* `Nagios Plugin Configuration `_ -* `Static Physical Plugin Configuration `_ +* `Static Physical Plugin Configuration `_ -* `Resource State Configuration `_ +* `Resource State Configuration `_ -* `Alarm State Configuration `_ +* `Alarm Severity Configuration `_ -* `Zabbix Configuration `_ +* `Zabbix Configuration `_ diff --git a/doc/source/nagios-config.rst b/doc/source/nagios-config.rst index a7230a9be..b4371a24c 100644 --- a/doc/source/nagios-config.rst +++ b/doc/source/nagios-config.rst @@ -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: @@ -64,7 +64,6 @@ Format - nagios_host: type: name: - ... 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-** or **-devstack - to resources of type nova.host with the same name. - - map all Nagios hosts named instance-** to nova.instance + - map all Nagios hosts named ``host-`` or ``-devstack`` + to resources of type ``nova.host`` with the same name. + - map all Nagios hosts named ``instance-`` 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-(.*) diff --git a/doc/source/nagios-devstack-installation.rst b/doc/source/nagios-devstack-installation.rst index 03b95d3f5..3e7bf28b2 100644 --- a/doc/source/nagios-devstack-installation.rst +++ b/doc/source/nagios-devstack-installation.rst @@ -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://:54321/my_site/omd*. - :: + You can now access your Nagios site here: *http://: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://:/my_site/omd* +7. In your browser, go to *http://:/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 diff --git a/doc/source/notifier-aodh-plugin.rst b/doc/source/notifier-aodh-plugin.rst index 513839e7d..0aeadaa33 100644 --- a/doc/source/notifier-aodh-plugin.rst +++ b/doc/source/notifier-aodh-plugin.rst @@ -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 diff --git a/doc/source/resource-state-config.rst b/doc/source/resource-state-config.rst index b2ecd99fc..a2f5e99b3 100644 --- a/doc/source/resource-state-config.rst +++ b/doc/source/resource-state-config.rst @@ -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: - original values: - - name: - operational_value: - - name: ... # can list several states for one aggregation - - aggregated values: - priority: ... # can list several aggregated states - ... +.. code:: yaml + category: RESOURCE + values: + - aggregated values: + priority: + original values: + - name: + operational_value: + - 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: diff --git a/doc/source/scenario-evaluator.rst b/doc/source/scenario-evaluator.rst index 0e20762bf..d6dd7a8df 100644 --- a/doc/source/scenario-evaluator.rst +++ b/doc/source/scenario-evaluator.rst @@ -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 */templates* folder. diff --git a/doc/source/static-physical-config.rst b/doc/source/static-physical-config.rst index b8230e9a8..7c8e9fb85 100644 --- a/doc/source/static-physical-config.rst +++ b/doc/source/static-physical-config.rst @@ -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: - id: - type: - state: - relationships: - - type: - name: - id: - relation_type: - - type: ... +.. code:: + entities: + - name: + id: + type: + state: + relationships: + - type: + name: + id: + relation_type: + - 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 diff --git a/doc/source/vitrage-first_steps.rst b/doc/source/vitrage-first_steps.rst index f2333f14d..6b779fee9 100644 --- a/doc/source/vitrage-first_steps.rst +++ b/doc/source/vitrage-first_steps.rst @@ -11,9 +11,9 @@ Before you start Installation ============ -- `Enable Vitrage in devstack `_ -- `Enable Vitrage in horizon `_ -- run ./stack.sh +- `Enable Vitrage in devstack `_ +- `Enable Vitrage in horizon `_ +- 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 `_ -- `Configure Nagios datasource `_ +- `Install Nagios on your devstack `_ +- `Configure Nagios datasource `_ 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 `_ -- `Alarm severity configuration `_ +- `Resource state configuration `_ +- `Alarm severity configuration `_ 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 diff --git a/doc/source/zabbix_vitrage.rst b/doc/source/zabbix_vitrage.rst index e2f4d560d..75fa3c061 100644 --- a/doc/source/zabbix_vitrage.rst +++ b/doc/source/zabbix_vitrage.rst @@ -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:///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 ::