Time series database Graphite seems to be falling into disfavor
1–10 of 83 posts
Re: Time series database Graphite seems to be falling into disfavor
#2I actually love Graphite's API. I've yet to find another solution that is as easy to use and has as many available functions (http://graphite.readthedocs.org/en/latest/functions.html).
For that reason we still use graphite's API, but not the UI or datastore. Whisper nor whatever the newer one is would survive the load we put on it.
Our setup looks like:
grafana -> graphite-api -> graphite-influxdb -> InfluxDB <- statsite (C impl of statsd) <- metrics
Re: Time series database Graphite seems to be falling into disfavor
#3Here I was thinking I would read some informative article on graphite, graphene and related carbon derivatives. Dear programmers: pick better names.
Re: Time series database Graphite seems to be falling into disfavor
#4I've been in search of a good time-series database solution for some time now, and have pretty much given up on it and am in the process of rolling my own: https://github.com/grisha/timeriver
My issues with the present state of TS isn't the volume. I was looking for using TS outside of the DevOps world. Everyday things like your heart rate over time, price of gas at the nearest station, number of people in line at your coffee shop, etc. All these are interesting, and Graphite/RRDTool/InfluxDB/etc did not seem like appropriate storage, because to use it with your other data (which is most likely in a relational DB of some kind) you need to export/import it and who wants that.
I call this problem "data seclusion". When data exists in some kind of an incompatible format (e.g. Whisper files), it will end up ignored because of that extra conversion step necessary to link it with your other data. Data in Graphite and such is mostly good for generating charts, but TS analysis is so much more than that, even at its simplest.
I think that the good old relational database is fine storage for TS and we gave up on it way too early, especially given what's new in PostgreSQL. Making it horizontally scalable, distributed, using consensus protocols, etc - these are not time series problems, these are database problems and we do not yet have a good solution for these. (We have many that "kind of" work, support some features but not others e.g. Cassandra). Projects like InfluxDB are mired in solving the wrong problem which will eventually get solved at the DB level.
More thoughts on the subject: http://grisha.org/blog/2015/03/28/on-time-series/ http://grisha.org/blog/2015/09/23/storing-time-series-in-pos... and http://grisha.org/blog/2015/05/04/recording-time-series/
Re: Time series database Graphite seems to be falling into disfavor
#5It looks like they (deliberately?) didn't mention the open source projects that were specifically build to address the shortcomings of graphite, like prometheus or opentsdb.
Re: Time series database Graphite seems to be falling into disfavor
#6I've been in search of a good time-series database solution for some time now, and have pretty much given up on it and am in the process of rolling my own: https://github.com/grisha/timeriver My issues with the present state of TS isn't the volume. I was looking for using TS outside of the DevOps world. Everyday things like your heart rate over time, price of gas at the nearest station, number of people in line at yo…
I'm responsible for a solution at $dayjob where I ended up feeding the data into multiple sources. I basically have incoming "events" and they get fed into Sentry (which in turn stores them in MySQL and Redis), InfluxDB (to use with Graphana), and soon Elastic Search (to use with Kibana). Each of these just provides a different way to visualize the data.
Re: Time series database Graphite seems to be falling into disfavor
#7I actually love Graphite's API. I've yet to find another solution that is as easy to use and has as many available functions ( http://graphite.readthedocs.org/en/latest/functions.html ). For that reason we still use graphite's API, but not the UI or datastore. Whisper nor whatever the newer one is would survive the load we put on it. Our setup looks like: grafana -> graphite-api -> graphite-influxdb -> InfluxDB <- st…
Is it the case even with the latest Grafana (2.5) that you still get more functionality by running graphite-influxdb as a middleman?
I have Grafana 1.9 pointed directly at InfluxDB 0.8 and here's one thing you _can't_ do: group a series by X, then plot only the top Y groups. Is that the sort of thing that using graphite-influxdb provides?
Re: Time series database Graphite seems to be falling into disfavor
#8It looks like they (deliberately?) didn't mention the open source projects that were specifically build to address the shortcomings of graphite, like prometheus or opentsdb.
The author most likely didn't mention them because they suffer from the same limiting assumptions that graphite does. When you're dealing with multidimensional changing metrics, opentsdb has the same issues graphite does.
Re: Time series database Graphite seems to be falling into disfavor
#9Can some one change heading so it is understood as software and not actual Graphite
Re: Time series database Graphite seems to be falling into disfavor
#10I actually love Graphite's API. I've yet to find another solution that is as easy to use and has as many available functions ( http://graphite.readthedocs.org/en/latest/functions.html ). For that reason we still use graphite's API, but not the UI or datastore. Whisper nor whatever the newer one is would survive the load we put on it. Our setup looks like: grafana -> graphite-api -> graphite-influxdb -> InfluxDB <- st…
Is it the case even with the latest Grafana (2.5) that you still get more functionality by running graphite-influxdb as a middleman? I have Grafana 1.9 pointed directly at InfluxDB 0.8 and here's one thing you _can't_ do: group a series by X, then plot only the top Y groups. Is that the sort of thing that using graphite-influxdb provides?
There are a lot of things missing from Influx's query language. The most glaring issue is that you can't do 'multi step math' e.g. you can't do something like 'average series A and series B into 5min buckets then sum them'.