Hello OpenStack-Discuss, when setting up telemetry (ceilometer, gnocci, aodh) I followed the documentation at https://docs.openstack.org/ceilometer/latest/install/cinder/install-cinder-u... to set up sending metrics for cinder to ceilomter. 1) The instruction to run cinder-volume-usage-audit as a timer / cron every 5 minutes

*/5 * * * * /path/to/cinder-volume-usage-audit --send_actions

has me confused. This would cause the usage data for the last full month, to be sent to the notifications queue every 5 minutes. There is no progress tracker or pointer limiting this to only sent data that has not yet been sent. Looking at how openstack-ansible configures this (https://github.com/openstack/openstack-ansible-os_cinder/blob/1af3003e163e09...) it seems they were aware that running this without bounds and every 5 minutes is wrong. I also opened a bug (https://bugs.launchpad.net/ceilometer/+bug/2024475) about this. 2) Extending on 1) I believe setting the

volume_usage_audit_period

in the cinder configuration, to e.g. month or hour, will already set the interval for which the data is emitted. Then the important thing is to only run cinder-volume-usage-audit in the same frequency. 3) Looking at the "--send_actions" options, I am wondering if the "create/delete" actions for volumes, snapshosts and backups are not sent by cinder anyways and why they would need to be sent again in batch and by cinder-volume-usage-audit? I am referring to

[oslo_messaging_notifications] driver = messagingv2

being enabled. This might also be the reasoning behind this bug, https://bugs.launchpad.net/openstack-ansible/+bug/1968734, asking for this parameter to be behind a config switch to avoid duplicate actions to be sent. 4) Thinking about the whole setup more questions arise * What happens when I run this more than once in the same interval? What will ceilometer do with the (redundant) data? * I am also wondering how well this single piece of software scales and how this could be split up more? * Is there no way to implement a pointer to allow running this command more often and only send "new data"? Just like the timestamp up to which data was sent. * What about any locking / coordination to enable multiple instances? Regards Christian