8.9. Using metering for compute resources

You can collect usage data of compute resources using Gnocchi. This time series database processes and stores measurement data of compute resources and provides access to it via REST API or the command-line tool.

Measurements can be sampled from such compute resources as virtual machines, VM disks and interfaces, compute networks, volumes, etc. All resources are being revised: if any attribute of a resource changes, this change is recorded in the history of the resource. For a VM, for example, you can measure the amount of allocated memory and virtual CPUs, as well as the memory and CPU usage.

An entity storing aggregates composed of a timestamp and value is called a metric. A metric is attached to a specific resource and associated to an archive policy. A policy defines how long aggregates are kept in a metric and how they are computed (minimum, maximum, average, etc.).

The following metrics are available for aggregation:

Table 8.9.1 Compute resource metrics
Metric Type Resource type Description
memory gauge instance Amount of RAM allocated to the VM, in megabytes
memory.usage gauge instance Percentage of RAM used by the VM
vcpus gauge instance Number of virtual CPUs allocated to the VM
cpu cumulative instance Amount of CPU time used by the VM, in nanoseconds
disk.device.read.requests cumulative instance_disk Number of read requests
disk.device.write.requests cumulative instance_disk Number of write requests
disk.device.read.bytes cumulative instance_disk Amount of data read, in bytes
disk.device.write.bytes cumulative instance_disk Amount of data written, in bytes
network.incoming.bytes cumulative instance_network_interface Incoming network traffic, in bytes
network.outgoing.bytes cumulative instance_network_interface Outgoing network traffic, in bytes
network.incoming.packets cumulative instance_network_interface Incoming network traffic, in packets
network.outgoing.packets cumulative instance_network_interface Outgoing network traffic, in packets
image.size gauge image Size of the uploaded image, in bytes
volume.size gauge volume Size of the volume, in gigabytes
snapshot.size gauge volume Size of the volume snapshot, in gigabytes
magnum.cluster gauge coe_cluster Number of Container Orchestration Engine (COE), that is, Kubernetes clusters

Cumulative metrics are polled every 5 minutes and increase over time, while gauge metrics are updated on events and show fluctuating values.

For gauge metrics, the default archive policy is ceilometer-low, and for cumulative metrics, it is ceilometer-low-rate. These policies imply that all computed aggregates are kept for one day with 5-minute granularity and for one month with 1-hour granularity. The difference between them is in aggregation methods they use: the ceilometer-low policy stores only mean values, while ceilometer-low-rate stores mean values, as well as the average of delta values per interval.

8.9.1. Enabling the metering service

Note

If you have already installed metering services via the admin panel, skip this section.

You can enable metering services in your compute cluster by doing one of the following:

  • If you have no compute cluster yet, deploy it and enable metering by adding the --enable-metering option to the vinfra service compute cluster create command. For example:

    # vinfra service compute create --nodes <node1_id>[,<node2_id>,...] --enable-metering

  • If you have already created the compute cluster, use the following command:

    # vinfra service compute cluster set --enable-metering

    Note

    The metering service will only take into account compute objects created after it has been enabled.

These commands open port 8041 and enable two Gnocchi services: gnocchi-api, an HTTP server, and gnocchi-metricd, a metric daemon.

8.9.2. Using Gnocchi command-line tool

After enabling metering, you can get access to your compute resource metrics either via REST API or by using the Gnocchi command-line tool. To be able to use the tool, do the following:

  1. Install the Gnocchi client:

    # yum install python-gnocchiclient

  2. Generate the admin OpenRC file:

    # kolla-ansible post-deploy
# source /etc/kolla/admin-openrc.sh

Now you can use the gnocchi command with the --insecure option. Refer to Securing OpenStack API traffic with SSL.

For example, you can perform the following tasks:

  1. View the existing resources:

    # gnocchi --insecure resource list -c id -c type -c project_id
+---------------+----------------------------+------------+
| id            | type                       | project_id |
+---------------+----------------------------+------------+
| 238597c7<...> | volume                     | c1bf1<...> |
| 3c78558f<...> | instance                   | c1bf1<...> |
| 44f1896f<...> | instance_network_interface | c1bf1<...> |
| 880e9efc<...> | instance_disk              | c1bf1<...> |
+---------------+----------------------------+------------+

    The output shows that the compute cluster hosts one virtual machine with one NIC and one disk that is also present as a volume.

  2. Check all the available metrics for the resources:

    # gnocchi --insecure metric list
+--------------+---------------------+-------------------------------+---------+-------------+
| id           | archive_policy/name | name                          | unit    | resource_id |
+--------------+---------------------+-------------------------------+---------+-------------+
| 243c7ac<...> | ceilometer-low      | disk.root.size                | GB      | 3c7855<...> |
| 365e454<...> | ceilometer-low-rate | network.outgoing.packets      | packet  | 44f189<...> |
| 4fbd3e8<...> | ceilometer-low-rate | disk.device.read.requests     | request | 880e9e<...> |
| 54519fa<...> | ceilometer-low      | compute.instance.booting.time | sec     | 3c7855<...> |
| 5e1406f<...> | ceilometer-low-rate | disk.device.write.bytes       | B       | 880e9e<...> |
| 66a96c2<...> | ceilometer-low      | vcpus                         | vcpu    | 3c7855<...> |
| 722ea97<...> | ceilometer-low      | memory                        | MB      | 3c7855<...> |
| 7c961ab<...> | ceilometer-low-rate | disk.device.write.requests    | request | 880e9e<...> |
| 87e9fb7<...> | ceilometer-low-rate | network.incoming.packets      | packet  | 44f189<...> |
| 9d56321<...> | ceilometer-low-rate | disk.device.read.bytes        | B       | 880e9e<...> |
| b8be8f7<...> | ceilometer-low-rate | cpu                           | ns      | 3c7855<...> |
| c1961bb<...> | ceilometer-low      | disk.ephemeral.size           | GB      | 3c7855<...> |
| c9b61e0<...> | ceilometer-low      | volume.size                   | GB      | 238597<...> |
| d06a58c<...> | ceilometer-low-rate | network.outgoing.bytes        | B       | 44f189<...> |
| e2d9981<...> | ceilometer-low-rate | network.incoming.bytes        | B       | 44f189<...> |
| eaac2b5<...> | ceilometer-low      | memory.usage                  | MB      | 3c7855<...> |
+--------------+---------------------+-------------------------------+---------+-------------+

  3. View measures for a particular metric. For example:

    # gnocchi --insecure measures show cpu --resource-id 3c78558f-08bf-47e2-ba3e-bdb13e7b25bb
+---------------------------+-------------+-------------+
| timestamp                 | granularity |       value |
+---------------------------+-------------+-------------+
| 2019-12-11T17:05:00+03:00 |       300.0 |  2.2756e+11 |
| 2019-12-11T17:10:00+03:00 |       300.0 |  2.8897e+11 |
| 2019-12-11T17:15:00+03:00 |       300.0 |  3.7367e+11 |
| 2019-12-11T17:20:00+03:00 |       300.0 |    4.64e+11 |
| 2019-12-11T17:25:00+03:00 |       300.0 |  7.6104e+11 |
+---------------------------+-------------+-------------+

    By default, the mean aggregation method is used. To obtain how much CPU time is consumed per interval, use the --aggregation rate:mean option:

    # gnocchi --insecure measures show cpu --aggregation rate:mean \
--resource-id 3c78558f-08bf-47e2-ba3e-bdb13e7b25bb
+---------------------------+-------------+---------------+
| timestamp                 | granularity |         value |
+---------------------------+-------------+---------------+
| 2019-12-11T17:10:00+03:00 |       300.0 | 61410000000.0 |
| 2019-12-11T17:15:00+03:00 |       300.0 | 84700000000.0 |
| 2019-12-11T17:20:00+03:00 |       300.0 | 90330000000.0 |
| 2019-12-11T17:25:00+03:00 |       300.0 |    2.9704e+11 |
| 2019-12-11T17:30:00+03:00 |       300.0 |      3.64e+11 |
+---------------------------+-------------+---------------+

You can see the full list of gnocchi commands in the OpenStack documentation.

8.9.3. Viewing resource usage per project

To get usage of compute resources allocated to all virtual machines that belong to a particular project, use the command vinfra service compute quotas show --usage <project_id>. For example:

# vinfra service compute quotas show 6ef6f48f01b640ccb8ff53117b830fa3 --usage
+---------------------------------+-------+
| Field                           | Value |
+---------------------------------+-------+
| compute.cores.limit             | 20    |
| compute.cores.used              | 2     |
| compute.ram.limit               | 40960 |
| compute.ram.used                | 4096  |
| k8saas.cluster.limit            | 10    |
| k8saas.cluster.used             | 0     |
| lbaas.loadbalancer.limit        | 10    |
| lbaas.loadbalancer.used         | 0     |
| network.floatingip.limit        | 10    |
| network.floatingip.used         | 0     |
| storage.gigabytes.default.limit | 1024  |
| storage.gigabytes.default.used  | 66    |
+---------------------------------+-------+

The output shows that VMs included in the project with the ID 62af79f31ae5488aa33077d02af48282 were allocated 2 vCPUs, 4 GB of RAM, and 66 GB of disk space.

Oct 06, 2020
Print