Monitoring Physical Network Bandwidth Using OpenStack Ceilometer

In this article by Chandan Dutta Chowdhury and Sriram Subramanian, author of the book, OpenStack Networking Cookbook, we will explore various means to monitor network resource utilization using Ceilometer.

(For more resources related to this topic, see here.)

Introduction

Due to the dynamic nature of virtual infrastructure and multitenancy, OpenStack administrators need to monitor the resources used by tenants. The resource utilization data can be used to bill the users of a public cloud and to debug infrastructure-related problems. Administrators can also use the utilization reports for better capacity planning.

In this post, we will look at OpenStack Ceilometer to meter the physical network resource utilization.

Ceilometer components

The OpenStack Ceilometer project provides you with telemetry services. It can collect the statistics of resource utilization and also provide threshold monitoring and alarm services.

The Ceilometer project is composed of the following components:

  • ceilometer-agent-central: This component is a centralized agent that collects the monitoring statistics by polling individual resources
  • ceilometer-agent-notification: This agent runs on a central server and consumes notification events on the OpenStack message bus
  • ceilometer-collector: This component is responsible for dispatching events to the data stores
  • ceilometer-api: This component provides the REST API server that the Ceilometer clients interact with
  • ceilometer-agent-compute: This agent runs on each compute node and collects resource utilization statistics for the local node
  • ceilometer-alarm-notifier: This component runs on the central server and is responsible for sending alarms
  • ceilometer-alarm-evaluator: This componentmonitors the resource utilization and evaluates the conditions to raise an alarm when the resource utilization crosses predefined thresholds

The following diagram describes how the Ceilometer components are installed on a typical OpenStack deployment:

Installation

An installation of any typical OpenStack service consists of the following steps:

  • Creating a catalog entry in keystone for the service
  • Installing the service packages that provide you with a REST API server to access the service

Creating a catalog entry

The following steps describe the creation of a catalog entry for the Ceilometer service:

  1. An OpenStack service requires a user associated with it for the authorization and authentication. To create a service user, use the following command and provide the password when prompted:
    openstack user create --password-prompt ceilometer
  2. This service user will need to have administrative privileges. Use the following command in order to add an administrative role to the service user:
    openstack role add --project service --user ceilometer admin
  3. Next, we will create a service record for the metering service:
    openstack service create --name ceilometer --description "Telemetry" metering
  4. The final step in the creation of the service catalog is to associate this service with its API endpoints. These endpoints are REST URLs to access the OpenStack service and provide access for public, administrative, and internal use:
    openstack endpoint create \
    --publicurl http://controller:8777 \
    --internalurl http://controller:8777 \
    --adminurl http://controller:8777 \
    --region RegionOne metering

Installation of the service packages

Let's now install the packages required to provide the metering service. On the Ubuntu system, use the following command to install the Ceilometer packages:

apt-get install ceilometer-api ceilometer-collector \
ceilometer-agent-central ceilometer-agent-notification \
ceilometer-alarm-evaluator ceilometer-alarm-notifier \
python-ceilometerclient

Configuration

The configuration of an OpenStack service requires the following information:

  • Service database-related details such as the database server address, database name, and login credentials in order to access the database. Ceilometer uses MongoDB to store the resource monitoring data. A MongoDB database user with appropriate access for this service should be created. Conventionally, the user and database name matches the name of the OpenStack service, for example, for the metering service, we will use the database user and database name as ceilometer.
  • A keystone user associated with the service (one that we created in the installation section).
  • The credentials to connect to the OpenStack message bus such as rabbitmq.

All these details need to be provided in the service configuration file. The main configuration file for Ceilometer is /etc/ceilometer/ceilometer.conf. The following is a sample template for the Ceilometer configuration. The placeholders mentioned here must be replaced appropriately.

  • CEILOMETER_PASS: This is the password for the Ceilometer service user
  • RABBIT_PASS: This is the message queue password for an OpenStack user
  • CEILOMETER_DBPASS: This is the MongoDB password for the Ceilometer database
  • TELEMETRY_SECRET: This is the secret key used by Ceilometer to sign messages

Let's have a look at the following code:

[DEFAULT]
...
auth_strategy = keystone
rpc_backend = rabbit
[keystone_authtoken]
...
auth_uri = http://controller:5000/v2.0
identity_uri = http://controller:35357
admin_tenant_name = service
admin_user = ceilometer
admin_password = CEILOMETER_PASS
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
[database]
...
connection = mongodb://ceilometer:CEILOMETER_DBPASS@controller:27017/ceilometer
[service_credentials]
...
os_auth_url = http://controller:5000/v2.0
os_username = ceilometer
os_tenant_name = service
os_password = CEILOMETER_PASS
os_endpoint_type = internalURL
os_region_name = RegionOne
[publisher]
...
telemetry_secret = TELEMETRY_SECRET

Starting the metering service

Once the configuration is done, make sure that all the Ceilometer components are restarted in order to use the updated configuration:

# service ceilometer-agent-central restart
# service ceilometer-agent-notification restart
# service ceilometer-api restart
# service ceilometer-collector restart
# service ceilometer-alarm-evaluator restart
# service ceilometer-alarm-notifier restart

The Ceilometer compute agent must be installed and configured on the Compute node to monitor the OpenStack virtual resources.

In this article, we will focus on using the SNMP daemon running on the Compute and Network node to monitor the physical resource utilization data.

Physical Network monitoring

The SNMP daemon must be installed and configured on all the OpenStack Compute and Network nodes for which we intend to monitor the physical network bandwidth.

The Ceilometer central agent polls the SNMP daemon on the OpenStack Compute and Network nodes to collect the physical resource utilization data.

The SNMP configuration

The following steps describe the process of the installation and configuration of the SNMP daemon:

  1. To configure the SNMP daemon on the OpenStack nodes, you will need to install the following packages:
    apt-get install snmpd snmp
  2. Update the SNMP configuration file, /etc/snmp/snmpd.conf, to bind the daemon on all the network interfaces:
    agentAddress udp:161
  3. Update the /etc/snmp/snmpd.conf file to create an SNMP community and to view and provide access to the required MIBs. The following configuration assumes that the OpenStack nodes, where the Ceilometer central agent runs, have addresses in the 192.168.0.0/24 Subnet:
    com2sec   OS_net_sec 192.168.0.0/24 OS_community
    group     OS_Group   any             OS_net_sec
    view     OS_view     included       .1   80
    access   OS_Group   ""             any noauth 0 OS_view none none
  4. Next, restart the SNMP daemon with the updated configuration:
    service snmpd restart
  5. You can verify that the SNMP data is accessible from the Ceilometer central agent by running the following snmpwalk command from the nodes that run the central agent. In this example, 192.168.0.2 is the IP of the Compute node running the SNMP daemon while the snmpwalk command itself is executed on the node running the central agent. You should see a list of SNMP OIDs and their values:
    snmpwalk -mALL -v2c -cOS_community 192.168.0.2

The Ceilometer data source configuration

Once the SNMP configuration is completed on the Compute and Network nodes, a Ceilometer data source must be configured for these nodes.

A pipeline defines the transformation of the data collected by Ceilometer. The pipeline definition consists of a data source and sink.

A source defines the start of the pipeline and is associated with meters, resources, and a collection interval. It also defines the associated sink.

A sink defines the end of the transformation pipeline, transformation applied on the data, and the method used to publish the transformed data. Sending a notification over the message bus is the commonly used publishing mechanism.

To use data samples provided by the SNMP daemon on the Compute and Network nodes, we will configure a meter_snmp data source with a predefined meter_sink in the Ceilometer pipeline on the Central node. We will use the OpenStack Controller node to run the central agent.

The data source will also map the central agent to the Compute and Network nodes.

In the /etc/ceilometer/pipeline.yaml file, add the following lines. This configuration will allow the central agent to poll the SNMP daemon on three OpenStack nodes with the IPs of 192.168.0.2, 192.168.0.3 and 192.168.0.4:

   - name: meter_snmp
     interval: 60
     resources:
         - snmp://OS_community@192.168.0.2
         - snmp://OS_community@192.168.0.3
         - snmp://OS_community@192.168.0.4
     meters:
       - "hardware.cpu*"
       - "hardware.memory*"
       - "hardware.disk*"
       - "hardware.network*"
     sinks:
       - meter_sink

Restart the Ceilometer central agent in order to load the pipeline configuration change:

# service ceilometer-agent-central restart

Sample Network usage data

With the SNMP daemon configured, the data source in place, and the central agent reloaded, the statistics of the physical network utilization will be collected by Ceilometer. Use the following commands to view the utilization data.

ceilometer statistics -m hardware.network.incoming.datagram -q resource=<node-ip>

You can use various meters such as hardware.network.incoming.datagram and hardware.network.outgoing.datagram. The following image shows some sample data:

All the meters associated with the physical resource monitoring for a host can be viewed using the following command, where 192.168.0.2 is the node IP as defined in the pipeline SNMP source:

ceilometer meter-list|grep 192.168.0.2

The following is the output of the preceding command:

How does it work

The SNMP daemon runs on each Compute and Network node. It provides a measure of the physical resources usage on the local node. The data provided by the SNMP daemon on the various Compute and Network nodes is collected by the Ceilometer central agent. The Ceilometer central agent must be told about the various nodes that are capable of providing an SNMP-based usage sample; this mapping is provided in the Ceilometer pipeline definition. A single central agent can collect the data from multiple nodes or multiple central agents can be used to partition the data collection task with each central agent collecting the data for a few nodes.

Summary

In this article, we learned the Ceilometer components, its installation and configuration. We also learned about monitoring physical network. You can also refer to the following books by Packt Publishing that can help you build your knowledge on OpenStack:

• OpenStack Cloud Computing Cookbook, Second edition by Kevin Jackson and Cody Bunch
• Learning OpenStack Networking (Neutron) by James Denton
• Implementing Cloud Storage with OpenStack Swift by Amar Kapadia, Sreedhar Varma, and Kris Rajana
• VMware vCloud Director Cookbook by Daniel Langenhan

Resources for Article:


Further resources on this subject:


You've been reading an excerpt of:

OpenStack Networking Cookbook

Explore Title