Difference between revisions of "ZenPack:OpenStack (Provider View)"

From Zenoss Wiki
Jump to: navigation, search
(55 intermediate revisions by 6 users not shown)
Line 4: Line 4:
 
|License=GNU General Public License, Version 2, or later
 
|License=GNU General Public License, Version 2, or later
 
|ZenPack name=ZenPacks.zenoss.OpenStackInfrastructure
 
|ZenPack name=ZenPacks.zenoss.OpenStackInfrastructure
|Homepage=https://github.com/zenoss/ZenPacks.zenoss.OpenStackInfrastructure
 
|Source URI=https://github.com/zenoss/ZenPacks.zenoss.OpenStackInfrastructure.git
 
 
|Flavor=free
 
|Flavor=free
 
|Releases={{Release
 
|Releases={{Release
|Version=3.0.0
+
|Version=2.0.0
|Tag=3.0.0
+
|Release date=2014/10/09
|Release date=2019/03/06
+
|Summary=Initial Version
|Compatible with=Zenoss Resource Manager 5.x.x
+
|Compatible with=Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x
|Requires=PythonCollector, OpenStack (Tenant View), Linux Monitor, ZenPackLib,
+
|Requires=PythonCollector, OpenStack (Tenant View)
 +
|Enhances=OpenStack Cloud Monitor
 +
}}{{Release
 +
|Version=2.1.0
 +
|Summary=Added Neutron Components
 +
|Compatible with=Zenoss Core 4.2.x, Zenoss Core 5.0.x, Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x
 +
|Requires=PythonCollector, OpenStack (Tenant View)
 
}}
 
}}
 
|Devices=
 
|Devices=
 
|Applications={{Application
 
|Applications={{Application
 
|Product Name=OpenStack Cloud Computing
 
|Product Name=OpenStack Cloud Computing
 +
|Version=Icehouse
 
}}
 
}}
 
|Integrations=
 
|Integrations=
 
|DataAudits=
 
|DataAudits=
 
}}
 
}}
Documentation for this zenpack may now be found at https://www.zenoss.com/product/zenpacks/openstack-provider-view
+
__TOC__
 +
This ZenPack allows for monitoring of OpenStack from a service provider
 +
perspective.  This means that in addition to the user-oriented components
 +
supported in the regular OpenStack ZenPack (instances, flavors, images), the
 +
underlying OpenStack servers and software are monitored.
 +
 
 +
=== Features ===
 +
 
 +
* Monitors Overall OpenStack state
 +
* Monitors Nova and Neutron health
 +
* Monitors multiple Tenant Infrastructure
 +
* Monitors Nova Services and components
 +
* Models and monitors Neutron Services and components
 +
* Impact and Root-Cause (Requires Zenoss Service Dynamics)
 +
 
 +
== Availability ==
 +
 
 +
{{note}} This ZenPack is currently in a controlled availability state for
 +
Zenoss customers. Please contact prodmgmt@zenoss.com before deploying the
 +
ZenPack.
 +
 
 +
=== Gallery ===
 +
 
 +
<gallery widths=125px heights=130px>
 +
osi_availabilityzones.png|Availability Zones
 +
osi_devicegraphs.png|Device Graphs
 +
osi_floatingips.png|Floating IP
 +
osi_hosts.png|Host
 +
osi_hypervisors.png|Hypervisor
 +
osi_images.png|Image
 +
osi_impact_instance.png|Impact Instance
 +
osi_impact_instance_with_floatingip.png|Impact with FloatingIP
 +
osi_impact_region.png|Impact Region
 +
osi_impact_tenant.png|Impact
 +
osi_instances.png|Instance
 +
osi_networks.png|Network
 +
osi_neutronagents.png|Neutron Agent
 +
osi_novaapis.png|Nova API
 +
osi_novaservices.png|Nova Service
 +
osi_openstackcomponentview.png|Component View
 +
osi_ports.png|Port
 +
osi_regions.png|Region
 +
osi_routers.png|Router
 +
osi_subnets.png|Subnet
 +
osi_tenants.png|Tenant
 +
osi_vnics.png|vNIC
 +
</gallery>
 +
 
 +
== Prerequisites ==
 +
 
 +
* OpenStack (Icehouse or newer)
 +
* Ceilometer-OpenStack compatible with your version of OpenStack
 +
* ceilometer_zenoss 1.0.0+ (https://github.com/zenoss/ceilometer_zenoss)
 +
** This Zenoss-specific plugin must be installed on your ceilometer nodes (see below)
 +
** If not installed and configured properly, Instances and vNICs graphs will be blank, and Zenoss will not detect changes (such as new instances or instance state changes) until a full model is performed.
 +
* PyYAML needs to be installed in order to use the YAML configuration
 +
** All 5.X versions of Zenoss have PyYAML already installed
 +
** Only 4.2.4 SP763 or 4.2.5 SP378 or earlier affected
 +
** You will have to add this Python package to your Zenoss installation otherwise
 +
** Update to the latest RPS or "easy_install pyyaml" manually if required.
 +
* SSH credentials to the Linux devices in your OpenStack environment
 +
** Configure the zCommandUsername/zCommandPassword properties on the /Devices/Server/SSH/Linux/NovaHost device class.
 +
** If your Linux devices are already managed under Zenoss, move them into /Devices/Server/SSH/Linux/NovaHost
 +
* Administrative credentials for your OpenStack environment
 +
** Username, password, keystone URL, Region
 +
 
 +
== Basic Usage ==
 +
 
 +
===Device Setup via UI===
 +
Once the OpenStack ZenPack is installed and you can begin monitoring by going
 +
to the infrastructure screen and clicking the normal button for adding devices.
 +
You'll find a new option labeled, "Add OpenStack Endpoint (Infrastructure)."
 +
 
 +
Choose that option and you'll be presented with a dialog asking for the following inputs.
 +
 
 +
# Device To Create - name to use for this device in Zenoss.  Should not be an actual hostname, since that name will be used when the host is registered as a Linux device.
 +
# Auth URL - A keystone URL, such as http://<hostname>:5000/v2.0/
 +
# Username, Password/API Key, Project/Tenant ID - *Administrative* credentials to your Zenoss instance.
 +
# Region Name - choose the correct region from the drop-down.  You may only choose one, so each region you wish to manage must be registered as a separate endpoint in Zenoss.
 +
# Ceilometer URL - Will auto-populate based on the other selections.
 +
 
 +
Once you click Add, Zenoss will contact the OpenStack API and discover servers,
 +
images and flavors. Once it is complete you'll find a new device in the
 +
OpenStack device class with the same name as the hostname or IP you entered
 +
into the dialog. Click into this new device to see everything that was
 +
discovered.
 +
 
 +
===Device Setup via Zenbatchload===
 +
 
 +
You can setup the device using *zenbatchload* as follows:
 +
 
 +
<syntaxhighlight lang="bash">zenbatchload file.txt</syntaxhighlight>
 +
 
 +
where *file.txt* should have the form:
 +
 
 +
<syntaxhighlight lang="text">
 +
/Devices/OpenStack/Infrastructure loader='openstackinfrastructure', loader_arg_keys=['deviceName', 'username', 'api_key', 'project_id', 'auth_url', 'ceilometer_url', 'region_name', 'collector']
 +
    mp8.osi username='admin', api_key='zenoss', project_id='admin', auth_url='http://192.168.117.47:5000/v2.0/', region_name='RegionOne'</syntaxhighlight>
 +
 
 +
* As before zCommandUsername/zCommandPassword properties must be set manually for /Devices/Server/SSH/Linux/NovaHost device class                                     
 +
 
 +
===Organizational Elements===
 +
;The following organizational elements are discovered:
 +
 
 +
* Regions
 +
* Availability Zones
 +
* Tenants
 +
 
 +
;The following virtual-machine elements are discovered:
 +
 
 +
* Nova Services (processes supporting nova servers)
 +
* Instances (Servers)
 +
* Hosts
 +
* Hypervisors
 +
* Images
 +
* Flavors
 +
* Nova API Endpoints
 +
 
 +
;The following network elements are discovered:
 +
* Neutron Agents
 +
* Networks
 +
* Subnets
 +
* Routers
 +
* Ports
 +
* Floating-Ips
 +
* vNICs (from NovaHost compute device model)
 +
 
 +
===Metrics===
 +
 
 +
;The following component level metrics are collected:
 +
 
 +
Instances
 +
* CPU Utilization (percent)
 +
* Disk Requests (requests/sec)
 +
* Disk IO Rate (bytes/sec)
 +
vNICs
 +
* Network Packet Rate (packets/sec)
 +
* Network Throughput (bytes/sec)
 +
Hosts (Zenoss Linux OS monitoring)
 +
* Load Average (processes)
 +
* CPU Utilization (percent)
 +
* Free Memory (bytes)
 +
* Free Swap (bytes)
 +
* IO (sectors/sec)
 +
Nova Services (Zenoss Process monitoring)
 +
* CPU Utilization (percent)
 +
* Memory Utilization (bytes)
 +
* Process Count (processes)
 +
Neutron Agents
 +
* CPU Utilization (percent)
 +
* Memory Utilization (bytes)
 +
* Process Count (processes)
 +
 
 +
;The following device level metrics are collected:
 +
 
 +
Flavors
 +
* Total (count)
 +
Images
 +
* Total (count)
 +
* Total count per image state
 +
Servers
 +
* Total (count)
 +
* Total count per server state
 +
Queues
 +
* Event (count)
 +
* Performance (count)
 +
Agents
 +
* Total (count)
 +
* Total count per agent type
 +
Networks
 +
* Total (count)
 +
* Total count per network state
 +
Routers
 +
* Total (count)
 +
* Total count per router state
 +
 
 +
 
 +
{{note}} All metrics collected by OpenStack Ceilometer may be collected and graphed in
 +
Zenoss, and all events processed through ceilometer are exposed via the
 +
Zenoss Event Console.
 +
 
 +
==Ceilometer Enablement==
 +
 
 +
Although you may add an OpenStack device to Zenoss, as shown above, event and
 +
performance data will not be collected until the following steps are performed.
 +
 
 +
===Zenoss Configuration Steps===
 +
 
 +
On the Zenoss host in Zenoss 4.X, or RabbitMQ container in Zenoss 5.X:
 +
 
 +
* ssh in as the Zenoss user:
 +
* export ZP_DIR=$ZENHOME/ZenPacks/ZenPacks.zenoss.OpenStackInfrastructure*
 +
* Now execute:
 +
 
 +
<syntaxhighlight lang="bash">
 +
  $ZP_DIR/ZenPacks/zenoss/OpenStackInfrastructure/bin/openstack_amqp_config
 +
</syntaxhighlight>
 +
 
 +
This script will create a new user in RabbitMQ and set up its permissions.  It
 +
will print out the proper values to use for amqp_hostname, amqp_port,
 +
amqp_userid, amqp_password, and amqp_virtualhost during ceilometer
 +
configuration (see below)
 +
 
 +
===OpenStack Ceilometer Configuration Steps===
 +
 
 +
Zenoss relies upon a ceilometer dispatcher plugin to ship raw event and
 +
metering data from ceilometer to Zenoss for storage in the Zenoss event
 +
and performance databases.  This integration is done by publishing messages
 +
to Zenoss's RabbitMQ server.
 +
 
 +
This dispatcher should be installed on all nodes running any ceilometer, but
 +
particularly those running ceilometer-collector or ceilometer-agent-notification.
 +
 
 +
To install it, perform the following steps on each of these OpenStack nodes (NOT
 +
on the Zenoss collector):
 +
 
 +
<syntaxhighlight lang="bash">
 +
  sudo pip -q install --force-reinstall https://github.com/zenoss/ceilometer_zenoss/archive/master.zip
 +
  sudo cp /usr/lib/*/site-packages/ceilometer_zenoss/event_definitions.yaml /etc/ceilometer/
 +
</syntaxhighlight>
 +
 
 +
Edit /etc/ceilometer/ceilometer.conf, and add the following lines to the
 +
appropriate sections:
 +
 
 +
<syntaxhighlight lang="text">
 +
  [DEFAULT]
 +
  dispatcher=zenoss
 +
 
 +
  [notification]
 +
  store_events=True
 +
</syntaxhighlight>
 +
 
 +
Also add the [dispatcher_zenoss] section reported by openstack_amqp_config above.
 +
 
 +
{{note}} Please restart all ceilometer services on all hosts after making these changes.
 +
 
 +
===Optional Steps===
 +
 
 +
====VM State Changes====
 +
 
 +
By default, instance state changes will be captured by Zenoss when certain
 +
events occur, for example, when an instance is shut down, the state change
 +
to SHUTDOWN will be reflected in Zenoss.
 +
 
 +
However, certain state changes that don't correspond to another defined event
 +
may not be picked up until the next time Zenoss models the environment.
 +
 
 +
If you would like to reduce the likelihood of this occurring, you can configure
 +
OpenStack Nova to send an event (through ceilometer) to Zenoss whenever
 +
any VM state change occurs by adding the following to nova.conf:
 +
 
 +
<syntaxhighlight lang="text">
 +
  [DEFAULT]
 +
  notify_on_state_change=vm_state
 +
</syntaxhighlight>
 +
 
 +
Note that this will cause increased event load, both on OpenStack and Zenoss,
 +
and additional processing within the event transforms in Zenoss to keep
 +
the model consistent.  Since most instance changes will still be caught
 +
without this option enabled, it is recommended to leave this disabled if your
 +
OpenStack environment is very large.
 +
 
 +
====Increasing Polling Interval====
 +
 
 +
Zenoss will process performance datapoints from ceilometer every 10 minutes,
 +
since by default, ceilometer will only produce one datapoint every 10 minutes.
 +
This can be adjusted by modifying the "interval: 600" line in your
 +
pipeline.yaml file (typically /etc/ceilometer/pipeline.yaml).
 +
 
 +
== Zenoss Analytics ==
 +
 
 +
This ZenPack provides additional support for Zenoss Analytics. Perform the
 +
following steps to install extra reporting resources into Zenoss Analytics
 +
after installing the ZenPack.
 +
 
 +
# Copy analytics-bundle.zip from $ZENHOME/ZenPacks/ZenPacks.zenoss.OpenStackInfrastructure*/ZenPacks/zenoss/OpenStackInfrastructure/analytics/ on your Zenoss server.
 +
# Navigate to Zenoss Analytics in your browser.
 +
# Login as superuser.
 +
# Remove any existing ''OpenStackInfrastructure ZenPack'' folder.
 +
## Choose ''Repository'' from the ''View'' menu at the top of the page.
 +
## Expand ''Public'' in the list of folders.
 +
## Right-click on ''OpenStackInfrastructure ZenPack'' folder and choose ''Delete''.
 +
## Confirm deletion by clicking ''OK''.
 +
# Add the new ''OpenStackInfrastructure ZenPack'' folder.
 +
## Choose ''Server Settings'' from the ''Manage' menu at the top of the page.
 +
## Choose ''Import'' in the left page.
 +
## Remove checks from all check boxes.
 +
## Click ''Choose File'' to import a data file.
 +
## Choose the analytics-bundle.zip file copied from your Zenoss server.
 +
## Click ''Import''.
 +
 
 +
You can now navigate back to the ''OpenStackInfrastructure ZenPack'' folder in the repository to see the following resources added by the bundle.
 +
 
 +
;Domains
 +
* OpenStackInfrastructure Domain
 +
 
 +
;Ad Hoc Views
 +
* OpenStack Instance List
 +
 
 +
Domains can be used to create ad hoc views using the following steps.
 +
 
 +
# Choose ''Ad Hoc View'' from the ''Create'' menu.
 +
# Click ''Domains'' at the top of the data chooser dialog.
 +
# Expand ''Public'' then ''OpenStackInfrastructure ZenPack''.
 +
# Choose the ''OpenStackInfrastructure Domain'' domain
 +
 
 +
 
 +
== Service Impact and Root Cause Analysis ==
 +
 
 +
When combined with the Zenoss Service Dynamics product, this ZenPack adds
 +
built-in service impact and root cause analysis capabilities for OpenStack
 +
infrastructure and instances. The service impact relationships shown in the
 +
diagram and described below are automatically added. These will be included in
 +
any services that contain one or more of the explicitly mentioned components.
 +
 
 +
[[File:impact.png|thumb|320px|Impact Relationship Diagram]]
 +
 
 +
===Recommended Impact Setup===
 +
 
 +
Since most components will be related to Tenants and Region we recommend:
 +
 
 +
* Navigate to Services (Impact)
 +
* Add a Dynamic Service to your Services tab
 +
* Add all Tenants to the Dynamic Service
 +
* Add all Regions to the Dynamic Service
 +
 
 +
===Impact Relations===
 +
 
 +
Component failures will affect Impact as follows:
 +
 
 +
;Internal Impact Relationships
 +
* OpenStack API endpoint impacts all Hosts
 +
* Availabilty zone impacts associated Region
 +
* Host impacts associated Hypervisors, Nova Services, Cells, Nova Apis, and Neutron Agents
 +
* Hypervisor impacts the resident Instances (VMs)
 +
* Nova Service affects the Availability Zone or Region that it supports
 +
* Instance impacts the associated Tenant
 +
* vNIC impacts the related Instance.
 +
* Port impacts associated Instance
 +
* Subnet impacts associated Ports and Tenants
 +
* Floating-IP impacts associated Port
 +
* Network impacts associated Subnets and Tenants
 +
* Router impacts associated Subnets and Floating-ips
 +
* Neutron Agent impacts associated Networks, Subnets and Routers
 +
 
 +
;External Impact Relationships
 +
* Instance impacts guest operating system device.
 +
* Cisco UCS vNIC impacts related host's underlying Linux device NIC.
 +
* Cisco UCS service profile impacts host's underlying Linux device.
 +
* Host impacted by associated Linux device.
 +
* OS Processes on an underlying Linux device impact corresponding Nova APIs and  Nova Services on Host.
 +
 
 +
 
 +
== Known Issues ==
 +
 
 +
# [https://jira.zenoss.com/browse/ZEN-14585 ZEN-14585]: The same endpoint can not be monitored both as user and an infrastructure endpoints.
 +
## Workaround: If you have been previously monitoring the endpoint as a User endpoint, delete the device before you re-add it as an Infrastructure endpoint.
 +
# [https://jira.zenoss.com/browse/ZEN-14491 ZEN-14491]: A stacktrace may occur during the initial modeling of the device
 +
## The trace will contain the error "ValueError: expected txn status 'Active' or 'Doomed', but it's 'Committed'"
 +
## Workaround: Disregard the error.  You may also manually model the device to confirm that no further errors are reported.
 +
# [https://jira.zenoss.com/browse/ZEN-17905 ZEN-17905]: Nova APIs component: Grey icons for Enabled and State after model/monitor.
 +
## OpenStack nova service API does not provide information about Nova-API, so its status is, in fact, unknown.
 +
 
 +
== Changes ==
 +
 
 +
;2.1.0
 +
* Added Neutron network components
 +
* Update Impact models for Neutron
 +
* Update multiple UI interfaces
 +
* Upgrade to ZenPackLib 1.0.1
 +
* Add ML2 Pluggin Capability
 +
* Add OpenvSwitch Integration
 +
 
 +
 
 +
;2.0.0
 +
* Initial Release
 
{{ZenPackFooter}}
 
{{ZenPackFooter}}

Revision as of 15:42, 29 May 2015

Organization
Zenoss, Inc.
License
GNU General Public License, Version 2, or later
ZenPack name
ZenPacks.zenoss.OpenStackInfrastructure


Applications Monitored: 



OpenStack (Provider View) ZenPack

This ZenPack allows for monitoring of OpenStack from a service provider perspective. This means that in addition to the user-oriented components supported in the regular OpenStack ZenPack (instances, flavors, images), the underlying OpenStack servers and software are monitored.

Warning

The ZenPack Catalog has moved to its new home at https://www.zenoss.com/product/zenpacks as of January 17, 2017. The following information may be out of date, and this page will eventually be removed.

Support

This is an Open Source ZenPack developed by Zenoss, Inc. Enterprise support for this ZenPack is available to commercial customers with an active subscription.

Releases

Version 2.0.0
Summary of changes: Initial Version
Released on 2014/10/09
Requires PythonCollector ZenPack,OpenStack (Tenant View) ZenPack
Compatible with Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x
Enhances OpenStack Cloud Monitor
Version 2.1.0
Summary of changes: Added Neutron Components
Requires PythonCollector ZenPack,OpenStack (Tenant View) ZenPack
Compatible with Zenoss Core 4.2.x, Zenoss Core 5.0.x, Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x

Background

This ZenPack allows for monitoring of OpenStack from a service provider perspective. This means that in addition to the user-oriented components supported in the regular OpenStack ZenPack (instances, flavors, images), the underlying OpenStack servers and software are monitored.

Features

  • Monitors Overall OpenStack state
  • Monitors Nova and Neutron health
  • Monitors multiple Tenant Infrastructure
  • Monitors Nova Services and components
  • Models and monitors Neutron Services and components
  • Impact and Root-Cause (Requires Zenoss Service Dynamics)

Availability

Bulbgraph.png Note: This ZenPack is currently in a controlled availability state for Zenoss customers. Please contact prodmgmt@zenoss.com before deploying the ZenPack.

Gallery

Prerequisites

  • OpenStack (Icehouse or newer)
  • Ceilometer-OpenStack compatible with your version of OpenStack
  • ceilometer_zenoss 1.0.0+ (https://github.com/zenoss/ceilometer_zenoss)
    • This Zenoss-specific plugin must be installed on your ceilometer nodes (see below)
    • If not installed and configured properly, Instances and vNICs graphs will be blank, and Zenoss will not detect changes (such as new instances or instance state changes) until a full model is performed.
  • PyYAML needs to be installed in order to use the YAML configuration
    • All 5.X versions of Zenoss have PyYAML already installed
    • Only 4.2.4 SP763 or 4.2.5 SP378 or earlier affected
    • You will have to add this Python package to your Zenoss installation otherwise
    • Update to the latest RPS or "easy_install pyyaml" manually if required.
  • SSH credentials to the Linux devices in your OpenStack environment
    • Configure the zCommandUsername/zCommandPassword properties on the /Devices/Server/SSH/Linux/NovaHost device class.
    • If your Linux devices are already managed under Zenoss, move them into /Devices/Server/SSH/Linux/NovaHost
  • Administrative credentials for your OpenStack environment
    • Username, password, keystone URL, Region

Basic Usage

Device Setup via UI

Once the OpenStack ZenPack is installed and you can begin monitoring by going to the infrastructure screen and clicking the normal button for adding devices. You'll find a new option labeled, "Add OpenStack Endpoint (Infrastructure)."

Choose that option and you'll be presented with a dialog asking for the following inputs.

  1. Device To Create - name to use for this device in Zenoss. Should not be an actual hostname, since that name will be used when the host is registered as a Linux device.
  2. Auth URL - A keystone URL, such as http://<hostname>:5000/v2.0/
  3. Username, Password/API Key, Project/Tenant ID - *Administrative* credentials to your Zenoss instance.
  4. Region Name - choose the correct region from the drop-down. You may only choose one, so each region you wish to manage must be registered as a separate endpoint in Zenoss.
  5. Ceilometer URL - Will auto-populate based on the other selections.

Once you click Add, Zenoss will contact the OpenStack API and discover servers, images and flavors. Once it is complete you'll find a new device in the OpenStack device class with the same name as the hostname or IP you entered into the dialog. Click into this new device to see everything that was discovered.

Device Setup via Zenbatchload

You can setup the device using *zenbatchload* as follows:

zenbatchload file.txt

where *file.txt* should have the form:

/Devices/OpenStack/Infrastructure loader='openstackinfrastructure', loader_arg_keys=['deviceName', 'username', 'api_key', 'project_id', 'auth_url', 'ceilometer_url', 'region_name', 'collector']
    mp8.osi username='admin', api_key='zenoss', project_id='admin', auth_url='http://192.168.117.47:5000/v2.0/', region_name='RegionOne'
  • As before zCommandUsername/zCommandPassword properties must be set manually for /Devices/Server/SSH/Linux/NovaHost device class

Organizational Elements

The following organizational elements are discovered
  • Regions
  • Availability Zones
  • Tenants
The following virtual-machine elements are discovered
  • Nova Services (processes supporting nova servers)
  • Instances (Servers)
  • Hosts
  • Hypervisors
  • Images
  • Flavors
  • Nova API Endpoints
The following network elements are discovered
  • Neutron Agents
  • Networks
  • Subnets
  • Routers
  • Ports
  • Floating-Ips
  • vNICs (from NovaHost compute device model)

Metrics

The following component level metrics are collected

Instances

  • CPU Utilization (percent)
  • Disk Requests (requests/sec)
  • Disk IO Rate (bytes/sec)

vNICs

  • Network Packet Rate (packets/sec)
  • Network Throughput (bytes/sec)

Hosts (Zenoss Linux OS monitoring)

  • Load Average (processes)
  • CPU Utilization (percent)
  • Free Memory (bytes)
  • Free Swap (bytes)
  • IO (sectors/sec)

Nova Services (Zenoss Process monitoring)

  • CPU Utilization (percent)
  • Memory Utilization (bytes)
  • Process Count (processes)

Neutron Agents

  • CPU Utilization (percent)
  • Memory Utilization (bytes)
  • Process Count (processes)
The following device level metrics are collected

Flavors

  • Total (count)

Images

  • Total (count)
  • Total count per image state

Servers

  • Total (count)
  • Total count per server state

Queues

  • Event (count)
  • Performance (count)

Agents

  • Total (count)
  • Total count per agent type

Networks

  • Total (count)
  • Total count per network state

Routers

  • Total (count)
  • Total count per router state


Bulbgraph.png Note: All metrics collected by OpenStack Ceilometer may be collected and graphed in Zenoss, and all events processed through ceilometer are exposed via the Zenoss Event Console.

Ceilometer Enablement

Although you may add an OpenStack device to Zenoss, as shown above, event and performance data will not be collected until the following steps are performed.

Zenoss Configuration Steps

On the Zenoss host in Zenoss 4.X, or RabbitMQ container in Zenoss 5.X:

  • ssh in as the Zenoss user:
  • export ZP_DIR=$ZENHOME/ZenPacks/ZenPacks.zenoss.OpenStackInfrastructure*
  • Now execute:
   $ZP_DIR/ZenPacks/zenoss/OpenStackInfrastructure/bin/openstack_amqp_config

This script will create a new user in RabbitMQ and set up its permissions. It will print out the proper values to use for amqp_hostname, amqp_port, amqp_userid, amqp_password, and amqp_virtualhost during ceilometer configuration (see below)

OpenStack Ceilometer Configuration Steps

Zenoss relies upon a ceilometer dispatcher plugin to ship raw event and metering data from ceilometer to Zenoss for storage in the Zenoss event and performance databases. This integration is done by publishing messages to Zenoss's RabbitMQ server.

This dispatcher should be installed on all nodes running any ceilometer, but particularly those running ceilometer-collector or ceilometer-agent-notification.

To install it, perform the following steps on each of these OpenStack nodes (NOT on the Zenoss collector):

  sudo pip -q install --force-reinstall https://github.com/zenoss/ceilometer_zenoss/archive/master.zip
  sudo cp /usr/lib/*/site-packages/ceilometer_zenoss/event_definitions.yaml /etc/ceilometer/

Edit /etc/ceilometer/ceilometer.conf, and add the following lines to the appropriate sections:

  [DEFAULT]
  dispatcher=zenoss
 
  [notification]
  store_events=True

Also add the [dispatcher_zenoss] section reported by openstack_amqp_config above.

Bulbgraph.png Note: Please restart all ceilometer services on all hosts after making these changes.

Optional Steps

VM State Changes

By default, instance state changes will be captured by Zenoss when certain events occur, for example, when an instance is shut down, the state change to SHUTDOWN will be reflected in Zenoss.

However, certain state changes that don't correspond to another defined event may not be picked up until the next time Zenoss models the environment.

If you would like to reduce the likelihood of this occurring, you can configure OpenStack Nova to send an event (through ceilometer) to Zenoss whenever any VM state change occurs by adding the following to nova.conf:

  [DEFAULT]
  notify_on_state_change=vm_state

Note that this will cause increased event load, both on OpenStack and Zenoss, and additional processing within the event transforms in Zenoss to keep the model consistent. Since most instance changes will still be caught without this option enabled, it is recommended to leave this disabled if your OpenStack environment is very large.

Increasing Polling Interval

Zenoss will process performance datapoints from ceilometer every 10 minutes, since by default, ceilometer will only produce one datapoint every 10 minutes. This can be adjusted by modifying the "interval: 600" line in your pipeline.yaml file (typically /etc/ceilometer/pipeline.yaml).

Zenoss Analytics

This ZenPack provides additional support for Zenoss Analytics. Perform the following steps to install extra reporting resources into Zenoss Analytics after installing the ZenPack.

  1. Copy analytics-bundle.zip from $ZENHOME/ZenPacks/ZenPacks.zenoss.OpenStackInfrastructure*/ZenPacks/zenoss/OpenStackInfrastructure/analytics/ on your Zenoss server.
  2. Navigate to Zenoss Analytics in your browser.
  3. Login as superuser.
  4. Remove any existing OpenStackInfrastructure ZenPack folder.
    1. Choose Repository from the View menu at the top of the page.
    2. Expand Public in the list of folders.
    3. Right-click on OpenStackInfrastructure ZenPack folder and choose Delete.
    4. Confirm deletion by clicking OK.
  5. Add the new OpenStackInfrastructure ZenPack folder.
    1. Choose Server Settings from the Manage' menu at the top of the page.
    2. Choose Import in the left page.
    3. Remove checks from all check boxes.
    4. Click Choose File to import a data file.
    5. Choose the analytics-bundle.zip file copied from your Zenoss server.
    6. Click Import.

You can now navigate back to the OpenStackInfrastructure ZenPack folder in the repository to see the following resources added by the bundle.

Domains
  • OpenStackInfrastructure Domain
Ad Hoc Views
  • OpenStack Instance List

Domains can be used to create ad hoc views using the following steps.

  1. Choose Ad Hoc View from the Create menu.
  2. Click Domains at the top of the data chooser dialog.
  3. Expand Public then OpenStackInfrastructure ZenPack.
  4. Choose the OpenStackInfrastructure Domain domain


Service Impact and Root Cause Analysis

When combined with the Zenoss Service Dynamics product, this ZenPack adds built-in service impact and root cause analysis capabilities for OpenStack infrastructure and instances. The service impact relationships shown in the diagram and described below are automatically added. These will be included in any services that contain one or more of the explicitly mentioned components.

Impact Relationship Diagram

Recommended Impact Setup

Since most components will be related to Tenants and Region we recommend:

  • Navigate to Services (Impact)
  • Add a Dynamic Service to your Services tab
  • Add all Tenants to the Dynamic Service
  • Add all Regions to the Dynamic Service

Impact Relations

Component failures will affect Impact as follows:

Internal Impact Relationships
  • OpenStack API endpoint impacts all Hosts
  • Availabilty zone impacts associated Region
  • Host impacts associated Hypervisors, Nova Services, Cells, Nova Apis, and Neutron Agents
  • Hypervisor impacts the resident Instances (VMs)
  • Nova Service affects the Availability Zone or Region that it supports
  • Instance impacts the associated Tenant
  • vNIC impacts the related Instance.
  • Port impacts associated Instance
  • Subnet impacts associated Ports and Tenants
  • Floating-IP impacts associated Port
  • Network impacts associated Subnets and Tenants
  • Router impacts associated Subnets and Floating-ips
  • Neutron Agent impacts associated Networks, Subnets and Routers
External Impact Relationships
  • Instance impacts guest operating system device.
  • Cisco UCS vNIC impacts related host's underlying Linux device NIC.
  • Cisco UCS service profile impacts host's underlying Linux device.
  • Host impacted by associated Linux device.
  • OS Processes on an underlying Linux device impact corresponding Nova APIs and Nova Services on Host.


Known Issues

  1. ZEN-14585: The same endpoint can not be monitored both as user and an infrastructure endpoints.
    1. Workaround: If you have been previously monitoring the endpoint as a User endpoint, delete the device before you re-add it as an Infrastructure endpoint.
  2. ZEN-14491: A stacktrace may occur during the initial modeling of the device
    1. The trace will contain the error "ValueError: expected txn status 'Active' or 'Doomed', but it's 'Committed'"
    2. Workaround: Disregard the error. You may also manually model the device to confirm that no further errors are reported.
  3. ZEN-17905: Nova APIs component: Grey icons for Enabled and State after model/monitor.
    1. OpenStack nova service API does not provide information about Nova-API, so its status is, in fact, unknown.

Changes

2.1.0
  • Added Neutron network components
  • Update Impact models for Neutron
  • Update multiple UI interfaces
  • Upgrade to ZenPackLib 1.0.1
  • Add ML2 Pluggin Capability
  • Add OpenvSwitch Integration


2.0.0
  • Initial Release

Installation

Normal Installation (packaged egg)

  1. Download the appropriate egg file for the version of Zenoss you are running.
  2. Ensure you are logged in as the zenoss user:
    $ sudo su - zenoss
  3. Install the ZenPack:
    $ zenpack --install ZenPacks.zenoss.OpenStackInfrastructure-*.egg
  4. Restart these services:
    $ zenoss restart

Developer Mode Installation

In order to do a development mode installation you will want to clone the existing git repository, and then use the --link flag with the zenpack command:

  1. Ensure you are logged in as the zenoss user:
    $ sudo su - zenoss
  2. Start by cloning the upstream repository:
    $ git clone git://github.com/path/to/repo
  3. Next, perform the installation:
    $ zenpack --link --install ZenPacks.zenoss.OpenStackInfrastructure
  4. Finally, restart these serivices:
    $ zenoss restart

Discuss

Purplemarker.png New: Don't forget to add yourself to the Zenoss User Map!

blog comments powered by Disqus