The Telemetry module collects meters within an OpenStack deployment. This section provides a brief summary about meters format and origin and also contains the list of available meters. Telemetry collects meters by polling the infrastructure elements and also by consuming the notifications emitted by other OpenStack services. For more information about the polling mechanism and notifications see . There are several meters which are collected by polling and by consuming. The origin for each meter is listed in the tables below. You may need to configure Telemetry or other OpenStack services in order to be able to collect all the samples you need. For further information about configuration requirements see the Telemetry chapter in the OpenStack Installation Guide. Also check the Telemetry manual installation description. Telemetry uses the following meter types:

Telemetry meter types

Type	Description
Cumulative	Increasing over time (instance hours)
Delta	Changing over time (bandwidth)
Gauge	Discrete items (floating IPs, image uploads) and fluctuating values (disk I/O)

Telemetry provides the possibility to store metadata for samples. This metadata can be extended for OpenStack Compute and OpenStack Object Storage. In order to add additional metadata information to OpenStack Compute you have two options to choose from. The first one is to specify them when you boot up a new instance. The additional information will be stored with the sample in the form of resource_metadata.user_metadata.*. The new field should be defined by using the prefix metering.. The modified boot command look like the following: $ nova boot --meta metering.custom_metadata=a_value my_vm The other option is to set the reserved_metadata_keys to the list of metadata keys that you would like to be included in resource_metadata of the instance related samples that are collected for OpenStack Compute. This option is included in the DEFAULT section of the ceilometer.conf configuration file. You might also specify headers whose values will be stored along with the sample data of OpenStack Object Storage. The additional information is also stored under resource_metadata. The format of the new field is resource_metadata.http_header_$name, where $name is the name of the header with - replaced by _. For specifying the new header, you need to set metadata_headers option under the [filter:ceilometer] section in proxy-server.conf under the swift folder. You can use this additional data for instance to distinguish external and internal users. The list of measurements is grouped by services which are polled by Telemetry or emits notifications that this module consumes. The Telemetry module supports storing notifications as events. This functionality was added later, therefore the list of meters still contains existence type and other event related items. The proper way of using Telemetry is to configure it to use the event store and turn off the collection of the event related meters. For further information about events see Events section in the Telemetry documentation. For further information about how to turn on and off meters see . Please also note that currently no migration is available to move the already existing event type samples to the event store.

The following meters are collected for OpenStack Compute: The Telemetry module supports to create new meters by using transformers. For more details about transformers see . Among the meters gathered from libvirt and Hyper-V there are a few ones which are generated from other meters. The list of meters that are created by using the rate_of_change transformer from the above table is the following: cpu_util disk.read.requests.rate disk.write.requests.rate disk.read.bytes.rate disk.write.bytes.rate disk.device.read.requests.rate disk.device.write.requests.rate disk.device.read.bytes.rate disk.device.write.bytes.rate network.incoming.bytes.rate network.outgoing.bytes.rate network.incoming.packets.rate network.outgoing.packets.rate To enable the libvirt memory.usage support, you need to install libvirt version 1.1.1+, Qemu version 1.5+, and you also need to prepare suitable balloon driver in the image. It is applicable particularly for Windows guests, most modern Linux distributions already have it built in. Telemetry is not able to fetch the memory.usage samples without the image balloon driver. OpenStack Compute is capable of collecting CPU related meters from the compute host machines. In order to use that you need to set the compute_monitors option to ComputeDriverCPUMonitor in the nova.conf configuration file. For further information see the Compute configuration section in the Compute chapter of the OpenStack Configuration Reference. The following host machine related meters are collected for OpenStack Compute:

Telemetry captures notifications that are emitted by the Bare metal module for OpenStack. The source of the notifications are IPMI sensors that collect data from the host machine. The sensor data is not available in the Bare metal module by default. To enable the meters and configure this module to emit notifications about the measured values see the Installation Guide for the Bare metal service. The following meters are recorded for the Bare metal module:

Another way of gathering IPMI based data is to use IPMI sensors independently from the Bare metal module's components. Same meters as could be fetched except that origin is Pollster instead of Notification. You need to deploy the ceilometer-agent-ipmi on each IPMI-capable node in order to poll local sensor data. For further information about the IPMI agent see . To avoid duplication of metering data and unnecessary load on the IPMI interface, do not deploy the IPMI agent on nodes that are managed by the Bare metal module and keep the conductor.send_sensor_data option set to False in the ironic.conf configuration file. Besides generic IPMI sensor data, the following Intel Node Manager meters are recorded from capable platform:

Telemetry supports gathering SNMP based generic host meters. In order to be able to collect this data you need to run smpd on each target host. The following meters are available about the host machines by using SNMP:

The following meters are collected for OpenStack Image Service:

The following meters are collected for OpenStack Block Storage:

The following meters are collected for OpenStack Object Storage:

In order to gather meters from Ceph, you have to install and configure the Ceph Object Gateway (radosgw) as it is described in the Installation Manual. You have to enable usage logging in order to get the related meters from Ceph. You will also need an admin user with users, buckets, metadata and usage caps configured. In order to access Ceph from Telemetry, you need to specify a service group for radosgw in the ceilometer.conf configuration file along with access_key and secret_key of the admin user mentioned above. The following meters are collected for Ceph Object Storage: The usage related information may not be updated right after an upload or download, because the Ceph Object Gateway needs time to update the usage properties. For instance, the default configuration needs approximately 30 minutes to generate the usage logs.

The following meters are collected for OpenStack Identity:

The following meters are collected for OpenStack Networking:

The following meters are collected for SDN: These meters are available for OpenFlow based switches. In order to enable these meters, each driver needs to be properly configured.

The following meters are collected for LBaaS:

The following meters are collected for VPNaaS:

The following meters are collected for FWaaS:

The following meters are collected for the Orchestration module:

The following meters are collected for the Data processing service for OpenStack:

The following meters are collected for the Key Value Store module:

The following energy related meters are available: