On Mon, Aug 31 2015, gord chung wrote: > i think that's the reason the bug is raised... that's not what cumulative > means. by definition it should increase over each successive value.
Well in a perfect world it would not, but with computers and numbers coded in bit it does. The bug about that is https://bugs.launchpad.net/ceilometer/+bug/1061817 and is quite old. > i'm not sure Gnocchi is where we should be fixing this as it really only > (potentially) fixes it for Gnocchi and not for any of the other ways > Ceilometer > data can be consumed. The ideal way is to send the data as it is collected and do the treatment in the backend, otherwise you end up implementing the world in Ceilometer. > a proposed solution in bug and in a previous thread suggests that a 'delta' > meter be built from cputime value libvirt provides which would better handle > the reset scenario. that said, is there another option to truly have a > cumulative meter? Yes, the hackish way might be to convert those cumulative to delta with a transfomer in the pipeline and be done with it. Though you'll probably have data points missing on restart, which is not ultimate solution. As soon as you start losing information in the Ceilometer pipeline by transforming I'll stand and say "bad idea". :-) So yes, you have to have a smart storage solution in the end. -- Julien Danjou // Free Software hacker // http://julien.danjou.info
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev