Advanced usage
Operations can be performed against metric, here an example with the metric cpu
Full documentation here
Display usage for the whole project
- Network in GB
openstack metric aggregates --resource-type=instance_network_interface --groupby=project_id "(/(aggregate rate:max (metric network.incoming.bytes max))1000000000)" "project_id!='dummy'" --granularity 3600
- Vcpus
openstack metric aggregates --resource-type=instance --groupby=project_id "(aggregate mean (metric vcpus mean))" "project_id!='dummy'" --granularity 3600
- Memory in GB
openstack metric aggregates --resource-type=instance --groupby=project_id "(/(aggregate mean (metric memory mean))1024)" "project_id!='dummy'" --granularity 3600
cpu load in nanoseconds
The only cpu metric available is cpu corresponding to the amount of CPU time used by the VM, in nanoseconds. It is a counter and therefore always increases over time (it is however reset in case of reboot).
Here is an example:
$ openstack metric measures show -r 0cc04d30-42c8-4afb-8666-cc932ec978e1 cpu
+---------------------------+-------------+----------------+
| timestamp | granularity | value |
+---------------------------+-------------+----------------+
| 2021-04-29T16:40:00+02:00 | 300.0 | 11000000000.0 |
| 2021-04-29T16:45:00+02:00 | 300.0 | 13280000000.0 |
+---------------------------+-------------+----------------+
The following command will give you the same result but will allow us to perform operations on it later :
$ openstack metric aggregates '(metric cpu mean)' id=0cc04d30-42c8-4afb-8666-cc932ec978e1
+---------------------------+-------------+----------------+
| timestamp | granularity | value |
+---------------------------+-------------+----------------+
| 2021-04-29T16:40:00+02:00 | 300.0 | 11000000000.0 |
| 2021-04-29T16:45:00+02:00 | 300.0 | 13280000000.0 |
+---------------------------+-------------+----------------+
In this example, the VM instance 0cc04d30-42c8-4afb-8666-cc932ec978e1 consumed 13280000000 - 11000000000 = 2 280 000 000 ns of CPU time between 2021-04-29T16:40:00+02:00 and 2021-04-29T16:45:00+02:00
We already store the delta between 2 consecutive measurements, so you can display it directly using the rate:mean metric instead of mean.
$ openstack metric aggregates '(metric cpu rate:mean)' id=0cc04d30-42c8-4afb-8666-cc932ec978e1
+----------------------------------------------------+---------------------------+-------------+-------------------+
| name | timestamp | granularity | value |
+----------------------------------------------------+---------------------------+-------------+-------------------+
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:45:00+00:00 | 300.0 | 2280000000.0 |
+----------------------------------------------------+---------------------------+-------------+-------------------+
We get the same value as calculated earlier: 2 280 000 000 ns
Another way to get the same result without using the rate:mean metric is to re-aggregate the values on the fly:
$ openstack metric aggregates '(aggregate rate:mean (metric cpu mean))' id=0cc04d30-42c8-4afb-8666-cc932ec978e1
+----------------------------------------------------+---------------------------+-------------+-------------------+
| name | timestamp | granularity | value |
+----------------------------------------------------+---------------------------+-------------+-------------------+
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:45:00+00:00 | 300.0 | 2280000000.0 |
+----------------------------------------------------+---------------------------+-------------+-------------------+
Once again, we get the value calculated earlier: 2 280 000 000 ns
cpu load in seconds
The cpu metric is expressed in nanoseconds, to convert it to seconds, divide by one billion:
$ openstack metric aggregates '(/ (metric cpu rate:mean) 1000000000 )' id=0cc04d30-42c8-4afb-8666-cc932ec978e1
+----------------------------------------------------+---------------------------+-------------+--------------------+
| name | timestamp | granularity | value |
+----------------------------------------------------+---------------------------+-------------+--------------------+
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:40:00+00:00 | 300.0 | 0.07 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:45:00+00:00 | 300.0 | 2.28 |
+----------------------------------------------------+---------------------------+-------------+--------------------+
cpu load
To express cpu load relatively to its maximum, we need to divide the cpu time used by the time elapsed, ensuring both are expressed in the same unit. One way to achieve this, is to convert the granularity to nanoseconds. For example, assuming a granularity of 300 seconds:
$ openstack metric aggregates '(/ (metric cpu rate:mean)
300000000000)' id=0cc04d30-42c8-4afb-8666-cc932ec978e1
+----------------------------------------------------+---------------------------+-------------+----------------------+
| name | timestamp | granularity | value |
+----------------------------------------------------+---------------------------+-------------+----------------------+
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:40:00+00:00 | 300.0 | 0.000233333333333334 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:45:00+00:00 | 300.0 | 0.0076 |
+----------------------------------------------------+---------------------------+-------------+----------------------+
0cc04d30-42c8-4afb-8666-cc932ec978e1 was 0.0076 (or 0.76%) between 2021-04-29T14:40:00+00:00 and 2021-04-29T14:45:00+00:00
Let's increase the load (in this case, by using the command stress) and check the cpu usage again:
$ openstack metric aggregates '(/ (metric cpu rate:mean) 300000000000 )' id=0cc04d30-42c8-4afb-8666-cc932ec978e1
+----------------------------------------------------+---------------------------+-------------+----------------------+
| name | timestamp | granularity | value |
+----------------------------------------------------+---------------------------+-------------+----------------------+
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:40:00+00:00 | 300.0 | 0.000233333333333334 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:45:00+00:00 | 300.0 | 0.0076 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:50:00+00:00 | 300.0 | 0.724266666666666 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T14:55:00+00:00 | 300.0 | 0.992766666666667 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T15:00:00+00:00 | 300.0 | 1.0021666666666667 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T15:05:00+00:00 | 300.0 | 0.996966666666667 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T15:10:00+00:00 | 300.0 | 1.0040666666666667 |
| 0cc04d30-42c8-4afb-8666-cc932ec978e1/cpu/rate:mean | 2021-04-29T15:15:00+00:00 | 300.0 | 1.0018333333333334 |
+----------------------------------------------------+---------------------------+-------------+----------------------+
We see that the cpu usage of the VM is roughly 1 (or one vcpu at 100%) starting at 2021-04-29T14:55:00+00:00.
Tip
Here are the rate:mean values corresponding to various cpu thresholds for the Infomaniak public cloud setup:
| CPU % | rate:mean | CPU % | rate:mean |
|---|---|---|---|
| 100 | 300000000000.0 | 50 | 150000000000.0 |
| 90 | 270000000000.0 | 40 | 120000000000.0 |
| 80 | 240000000000.0 | 30 | 90000000000.0 |
| 70 | 210000000000.0 | 20 | 60000000000.0 |
| 60 | 180000000000.0 | 10 | 30000000000.0 |
Acknowledgment
Some of the content on this page is derived from Bernd Bausch's article How I Learned to Stop Worrying and Love Gnocchi aggregation.