> >> On 8/11/2014 4:22 PM, Eoghan Glynn wrote: > >>>> Hi Eoghan, > >>>> > >>>> Thanks for the note below. However, one thing the overview below does > >>>> not > >>>> cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged. > >>>> Many > >>>> folks feel that this technology is a viable solution for the problem > >>>> space > >>>> discussed below. > >>> Great question Brad! > >>> > >>> As it happens we've been working closely with Paul Dix (lead > >>> developer of InfluxDB) to ensure that this metrics store would be > >>> usable as a backend driver. That conversation actually kicked off > >>> at the Juno summit in Atlanta, but it really got off the ground > >>> at our mid-cycle meet-up in Paris on in early July. > >> ... > >>> The InfluxDB folks have committed to implementing those features in > >>> over July and August, and have made concrete progress on that score. > >>> > >>> I hope that provides enough detail to answer to your question? > >> I guess it begs the question, if influxdb will do what you want and it's > >> open source (MIT) as well as commercially supported, how does gnocchi > >> differentiate? > > Hi Sandy, > > > > One of the ideas behind gnocchi is to combine resource representation > > and timeseries-oriented storage of metric data, providing an efficient > > and convenient way to query for metric data associated with individual > > resources. > > Doesn't InfluxDB do the same?
InfluxDB stores timeseries data primarily. Gnocchi in intended to store strongly-typed OpenStack resource representations (instance, images, etc.) in addition to providing a means to access timeseries data associated with those resources. So to answer your question: no, IIUC, it doesn't do the same thing. Though of course these things are not a million miles from each other, one is just a step up in the abstraction stack, having a wider and more OpenStack-specific scope. > > Also, having an API layered above the storage driver avoids locking in > > directly with a particular metrics-oriented DB, allowing for the > > potential to support multiple storage driver options (e.g. to choose > > between a canonical implementation based on Swift, an InfluxDB driver, > > and an OpenTSDB driver, say). > Right, I'm not suggesting to remove the storage abstraction layer. I'm > just curious what gnocchi does better/different than InfluxDB? > > Or, am I missing the objective here and gnocchi is the abstraction layer > and not an influxdb alternative? If so, my apologies for the confusion. No worries :) The intention is for gnocchi to provide an abstraction over timeseries, aggregation, downsampling and archiving/retention policies, with a number of drivers mapping onto real timeseries storage options. One of those drivers is based on Swift, another is in the works based on InfluxDB, and a third based on OpenTSDB has also been proposed. Cheers, Eoghan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev