Here I was thinking I would read some informative article on graphite, graphene and related carbon derivatives. Dear programmers: pick better names.
Naming is a hard problem in computer science :)
Time series database Graphite seems to be falling into disfavor
51–60 of 83 posts
Re: Time series database Graphite seems to be falling into disfavor
#52What does a modern metrics stack look like? There are so many words... Graphfana, Kibana, StatsD, Graphite, etc. Which bits should I choose and attach together?
Prometheus is really the answer here. http://prometheus.io
Prometheus with grafana for visualization. I've got some ideas about trying to run automated correlation queries for peaks and the like but they're probably above my skill level.
I have had some decent luck with sending syslog into mtail and counting generic word events like 'error' and 'warning' as a way to do "something might be wrong" alerting.
Re: Time series database Graphite seems to be falling into disfavor
#53Earlier quoted context omitted.
Wavefront looks like it's probably closed source. Is this true?
Yes, sorry if that wasn't clear.
And do they have a self-hosted solution?
The proprietary vs open argument is less important then the argument over where the data is physically held and ownership of it.
Re: Time series database Graphite seems to be falling into disfavor
#54Earlier quoted context omitted.
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.
Graphite's data model doesn't support multidimensional metrics which is in my opinion it's biggest shortcoming. To support multidimensional data, a suitable data model is needed. AFAIK influxdb stores all label dimensions and the value for each data point. No matter how high your cardinality is, the storage requirement is the same. If you need to have, let say, a dimension 'client_ip' in a metrics http_response_time,…
Though I'm a Prometheus author, I need to defend InfluxDB here :) Since 0.9.0, they support tags (vs. fields), which store indexed dimensions similarly to how Prometheus does it. So this argument doesn't count anymore. Still, there are many other differences in scope and functionality between the two systems.
Re: Time series database Graphite seems to be falling into disfavor
#55Earlier quoted context omitted.
Prometheus is really the answer here. http://prometheus.io
> What does a modern metrics stack look like? There are so many words... Graphfana, Kibana, StatsD, Graphite, Prometheus etc. Which bits should I choose and attach together?
Kibana is more logging, but Promethues covers the StatsD and Graphite requirements out of the box. Graphfana is one visualisation option to go with that (http://www.robustperception.io/setting-up-grafana-for-promet...).
Re: Time series database Graphite seems to be falling into disfavor
#56I 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…
Try out Prometheus, you can get it up and running a few minutes. It supports all the functions Graphite does, bar sin() and the Holt Winters functions which we plan on adding.
Re: Time series database Graphite seems to be falling into disfavor
#57If you prefer running an open-source solution yourself, Prometheus (http://prometheus.io/) addresses exactly those points and works especially well in a dynamic cloud / microservices / container scheduler world.
It has a dimensional data model, a powerful query language to go with it, and covers aspects from instrumentation to storing data, all the way to alerting and dashboarding. The latest version of Grafana has native Prometheus support now too. Many tools (like Kubernetes or etcd) already export Prometheus metrics natively, so you can monitor them with Prometheus right out of the box. Support for many kinds of service discovery (Kubernetes, Marathon, EC2, Consul, ...) make it work very well to monitor dynamically scheduled services as well. Disclaimer: Prometheus author.
Re: Time series database Graphite seems to be falling into disfavor
#58Graphite is ugly. Graphite is hard to use beyond just clicking a few graphs. Graphite requires some hard work to extend. But I am still using Graphite because 1) it is simple to set up! 2) nice to have a fixed-size flat file as database, although performance degrades very quickly. Cache misses is too frequent. 3) over raw socket is also quite attractive No other solution can compete with Graphite for its simplicity.…
At scales when it starts breaking one doesn't directly consume the metrics. In our setup of over 500K metrics/min, we had scripts consuming app metrics from graphite and pushing them back into a different, higher hierarchy which was then consumed by graphiti/grafana.
The Graphite URL API was visionary, and still makes the cut in most common use-cases.
Re: Time series database Graphite seems to be falling into disfavor
#59title should rather be "no more hype for Graphite".
Re: Time series database Graphite seems to be falling into disfavor
#60Earlier quoted context omitted.
Yes, sorry if that wasn't clear.
And do they have a self-hosted solution? The proprietary vs open argument is less important then the argument over where the data is physically held and ownership of it.
Agreed. I built an in-house mobile crash reporting solution even though the commercial options range from decent to excellent because none of them offered self-hosted, nor a way to export your data. We really wanted the data because it's allowed us to determine the cause of crashes and answer other questions that we otherwise couldn't w/o the raw data. There were also privacy concerns, even though in theory crash reports shouldn't have any PII. And we really don't need third parties knowing our DAU numbers and whatever else in any case.
There are finally some self-hosted commercial options in this space, but we've already built our solution and it works well.