I really want to love influxdb because I think the world needs a better answer to time series databases that doesn't include java (OpenTSDB, Cassandra). The underlying storage engine (leveldb/rocksdb) is quite solid. I'm currently running 3 nodes in production (for collecting stats) and doing a few thousand writes/s. I'm not using any of the clustering features, I probably won't even evaluate that until 0.9.<p>I'm currently running the latest 0.8.x release and there are a few issues:<p>1.My influxdb instances stop servicing reads once every 12 hours so I have a cron job that force restarts it. <a href="https://github.com/influxdb/influxdb/issues/1116" rel="nofollow">https://github.com/influxdb/influxdb/issues/1116</a><p>2. Enabling the graphite plugin on the first run can crash the process (the creation of the default cluster admin user seems to be racy). Not a big deal except in automated deployment scenarios.<p>3. I lost an entire database (luckily it was just used for storing grafana graph definitions and not actual data).<p>4. I'm not sure if anyone's currently working on their admin UI. I submitted a pull request to their admin UI to sort shards by ID because currently it randomizes the order on every load (I presume because of golang's randomized map iteration). It's sat there since January. The last PR they merged into that repo was in May of 2014.<p>I really want influxdb to be successful. Every organization I've worked for in the last few years has serious graphite scaling issues and influxdb is well positioned to fix those. I think even in it's current state it's a better option than graphite (and the influxdb-graphite plugin gives you all the graphite features).
Another InfluxDB user here. I'd done some evaluations with OpenTSDB and the Graphite suite, and while I had some concerns with stability and maturity the main things that sold me on it were:<p>* No dependencies. Compare this with setting up HDFS/HBase and Graphite which is a real pain in the neck to manage, especially since my tsdb has to run on an arbitrary machine pool in a sandbox.<p>* Active development. This is a big one. Releases have been coming steadily and Paul & co. do a good job of having a real roadmap and chipping away at it; this is probably my tipping point over Graphite.<p>* Clustering. Maybe it's not there yet, but see above. Most tools in this space are not elastic at all.<p>* Grafana integration - seems like there is a good bit of momentum in that project in general which is promising.<p>PS Reading this it almost sounds like an ad, no I'm not affiliated with influx.<p>PPS logfile configuration for rotation/cleanup would be a nice-to-have enhancement ;)
Incidently I wrote a blog on it last week: <a href="http://grisha.org/blog/2015/03/20/influxdb-data/" rel="nofollow">http://grisha.org/blog/2015/03/20/influxdb-data/</a><p>The site says "production ready in March" - it seemed to me like there's at least 3 months of work there given that most of the clustering features (e.g. how to rebuild a fialed node, how to expand the cluster, distributed queries) are not there.<p>My other concern with InfluxDB is that it doesn't follow the fate of FoundationDB - get acquired by a giant corporation and disappear.
I am using InfluxDB in my research, to analyze resource utilizations of running applications and it has been very useful to me since, but I think it was supposed to be production ready this March. There are some bugs that occurs sometimes.