On 05/04/2012 11:50 AM, Thierry Carrez wrote: > Robert Collins wrote: >> On Fri, May 4, 2012 at 5:27 AM, Turner, Whit (Cloud Services) >> <[email protected]> wrote: >>> Hi - I think a flexible aggregation scheme is needed; the levels of >>> aggregation available should be definable in the meter independent of the >>> sources of usage data themselves. If invoices need to be very granular down >>> to the lowest possible level, then this drives higher data requirements all >>> through the processing chain, including the rating engine. Traditional >>> systems tend to pass less granular (more highly aggregated) data into the >>> rating engine so that bill runs and invoices can be generated efficiently. >>> At cloud-scale, this can be problematic. Given some “big data” approaches, >>> though, this could be handled in a more granular and real-time fashion. >> Has anyone looked at what statsd does? It has very similar >> requirements (simple to use, no hard a-priori definition of things to >> count, a few base types to track), and needs to be horizontally >> scalable. > Also Swift has plans to use statsd for instrumentation/monitoring, so > it's definitely worth a look to see if it could be used here as well. > > http://folsomdesignsummit2012.sched.org/event/d9135eabdd775432c74c3f1d32a325d3 > http://etherpad.openstack.org/FolsomSwiftStatsd > Thanks :-) Just saved the etherpad as http://etherpad.openstack.org/ep/pad/view/FolsomSwiftStatsd/9cy8Uxtp2U in case it is vandalized.
Cheers -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ [email protected] ☎ +33 1 49 70 99 82 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
