Hey Andres, In my experience with usage gathering consolidating statistics at the root layer is usually a bad idea. The reason is that you lose potentially useful information once you consolidate data. When it comes to troubleshooting issues (such as billing) this lost information can cause problems since there is no way to "replay" what had actually happened. That said, there is no free lunch and keeping track of huge amounts of data can be a huge engineering challenge. We have a separate thread on what kinds of metrics we want to expose from the LBaaS service so perhaps it would be nice to understand these in more detail.
Cheers, --Jorge From: <Buraschi>, Andres <andres.buras...@intel.com<mailto:andres.buras...@intel.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, June 10, 2014 3:34 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal Hi, we have been struggling with getting a meaningful set of metrics from LB stats thru ceilometer, and from a discussion about module responsibilities for providing data, an interesting idea came up. (Thanks Pradeep!) The proposal is to consolidate some kinds of metrics as pool up time (hours) and average or historic response times of VIPs and listeners, to avoid having ceilometer querying for the state so frequently. There is a trade-off between fast response time (high sampling rate) and reasonable* amount of cumulative samples. The next step in order to give more detail to the idea is to work on a use cases list to better explain / understand the benefits of this kind of data grouping. What dou you think about this? Do you find it will be useful to have some processed metrics on the loadbalancer side instead of the ceilometer side? Do you identify any measurements about the load balancer that could not be obtained/calculated from ceilometer? Perhaps this could be the base for other stats gathering solutions that may be under discussion? Andres
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
