Yep. I'll repost an older comment of mine:

Development of graphite is effectively dead. The datastore component (carbon and whisper) has design issues, and the official replacement (ceres) hasn't seen any commits this year. There are a some alternatives, though.

For data storage Cyanite [0] speaks the graphite protocol and stores the data in Cassandra. Alternately, InfluxDB [1] speaks the graphite protocol and stores the data in itself

To get the data back out, there's graphite-api [2] which can be hooked up to cyanite [3] or influxdb [4]. You can then connect any graphite dashboard you like, such as grafana [5], to it.

[0] https://github.com/pyr/cyanite [1] http://influxdb.com [2] https://github.com/brutasse/graphite-api [3] https://github.com/brutasse/graphite-cyanite [4] https://github.com/vimeo/graphite-influxdb [5] http://grafana.org

Any idea on the performance of InfluxDB, I want to log ~500GB per hour in a timeseries DB. Can influx DB handle that?

The upcoming release should be able to handle that kind of load. I wrote a bit about what's coming here: http://influxdb.com/blog/2014/12/08/clustering_tags_and_enha...

any idea what happened to the project that resulted in this halt?

It was originally written and open sourced by Chris Davis of Orbitz. Presumably he either moved on to a new job, got bored with it, or it met his original design goals so he didn't feel the need to completely rewrite the backend just because the internet asked him to.

Surprising that with quite a few core contributors and (as far as I'm aware) pretty good adoption nobody picked it up though...

FWIW I've found influxdb considerably easier to install and manage than graphite (graphite doesn't play well with virtualenv, which makes dependency management horrible, compared to influxdb's single static binary)

Also, I can see logging dictionaries being much more efficient and useful than logging single values -- with graphite if you want to track page hits per section of your site (of which you have 10) per user (100) per browser (5), you end up with 5000 individual metrics, and you need to have thought of them in advance. With influxdb you can log {"section": "front page", "user": "bob", "browser": "firefox", "hits": 1} as a single metric and then use an SQL-like query to filter by section / user / browser (or any combination of those) as and when you want to.

TBH the only thing I miss going from graphite to influxdb+grafana is the tree of metrics (grafana has autocomplete once you start typing, but you can't just browse) and a few of the rendering functions (moving average).

I think the tagging features in the upcoming 0.9.0 release [1] will help with the navigation of metrics. With that we're adding new types of queries to help in discovery. [2]

[1] - http://influxdb.com/blog/2014/12/08/clustering_tags_and_enha... [2] - https://github.com/influxdb/influxdb/blob/master/QUERIES.md#...

Totally in the InfluxDB camp too.

I've spent the last week working on upgrading our Graphite system. I ultimately killed it and went with InfluxDB. The ease of installation and cluster creation were clear winners.

Additionally the storage options for Influx trump Graphite across the board. I tried writing a custom backend and it went nowhere. The docs and code are terrible. I also noticed that Ceres hasn't had a commit in a year - kind of disheartening.

Graphite's rendering functions are its real beauty. I looked at both OpenTSDB and InfluxDB as replacements, and neither have anything close to the power of Graphite's rendering.

I haven't been thrilled with grafana as a dashboard for OpenTSDB, either. I hadn't seen Cyanite.

Is there a workaround to get a moving average?

How does Graphite, and Influxdb compare to say an ELK stack?

Right now I'm in the process of setting up a Log aggregation/metrics system for PCI logging, and general server stats. Right now I'm using Elasticsearch, with Logstash and Kibana, and then piping OSSEC logs into Elasticsearch for security logging. I like the idea of this ELK stack, but it's not very polished imo.

Graphite is "numbers only." You can't throw logs at it.

Influxdb will be more similar to ElasticSearch, in that it will accept logs and events, and let you query and generate graphs and subsets of the data.

ElasticSearch has more mature clustering/scaling, and last time I checked, much more efficient queries. I don't know if Influx is winning the polish game, but I suspect it depends on your use case.

(disclaimer: bonsai.io founder)

Graphite compliments the ELK stack and does not replace it.

Logstash is great at extracting metrics/numbers/data out of your logs. You can then use the graphite/statsd output plugin to graph that data.