Nova's got this REST API [1] which pulls task_log data from the nova database if the 'instance_usage_audit' config option value is True on any compute host.

That table is populated in a periodic task from all computes that have it enabled and by default it 'audits' instances created in the last month (the time window is adjustable via the 'instance_get_active_by_window_joined' config option).

The periodic task also emits a 'compute.instance.exists' notification for each instance on that compute host which falls into the audit period. I'm fairly certain that notification is meant to be consumed by Ceilometer which is going to store it in it's own time-series database.

It just so happens that Nova is also storing this audit data in it's own database, and never cleaning it up - the only way in-tree to move that data out of the nova.task_log table is to archive it into shadow tables, but that doesn't cut down on the bloat in your database. That os-instance-usage-audit-log REST API is relying on the nova database though.

So my question is, is anyone using this in any shape or form, either via the Nova REST API or Ceilometer? Or are you using it in one form but not the other (maybe only via Ceilometer)? If you're using it, how are you controlling the table growth, i.e. are you deleting records over a certain age from the nova database using a cron job?

Mike Bayer was going to try and find some large production data sets to see how many of these records are in a big and busy production DB that's using this feature, but I'm also simply interested in how people use this, if it's useful at all, and if there is interest in somehow putting a limit on the data, i.e. we could add a config option to nova to only store records in the task_log table under a certain max age.

[1] http://developer.openstack.org/api-ref/compute/#server-usage-audit-log-os-instance-usage-audit-log

--

Thanks,

Matt Riedemann


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to