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-ubuntu.html 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/1af3003e163e09f917dd124ae874f1bea6fe2c6b/tasks/main.yml#L147) 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