Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time series database Graphite seems to be falling into disfavor

vividcortex.com

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Time series database Graphite seems to be falling into disfavor

#41

Post by svckr »

js2 wrote: post #6
gtrubetskoy wrote: post #4

I'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.

I find it confusing that these solutions seem to conflate time series storage/querying with visualization. Is there a reason for this?

I recall that Kibana is a plugin for Elastic Search but don't know about the others. Isn't it possible to connect a hypothetical standalone visualization frontend to any TSDB?

Re: Time series database Graphite seems to be falling into disfavor

#42

Post by chaotic-good »

cbsmith wrote: post #17
gtrubetskoy wrote: post #4

I'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 highly recommend looking at Keogh's work, particularly the iSAX and iSAX2 stuff: http://www.cs.ucr.edu/~eamonn/SAX.htm While it is used for machine learning, it actually makes a lot of sense to follow a similar approach for more general time series applications.

SAX requires different type of storage. You can store SAXified time series in ElasticSearch, or Solr but time-series database doesn't fit for this. Time-series databases should be able to generate SAX representation.

Re: Time series database Graphite seems to be falling into disfavor

#43

Post by giuliano108 »

mintplant wrote: post #37
dang wrote: post #22

Earlier quoted context omitted.

Ok, we changed the title to use representative language from the article. Btw, this article was heavily flagged. It's not really legit to flag a story just because people don't like the title. Plenty of good stories have problematic titles. Depriving others of a chance to read the content, especially when there's a good discussion going on in the thread, is a bad use of flagging power.

I didn't flag it, but perhaps others did because the author is a Graphite competitor, yet this isn't disclosed until the end.

Not a lot of useful information for such a long article.

Re: Time series database Graphite seems to be falling into disfavor

#44

Post by 23david »

fapjacks wrote: post #31
Karunamon wrote: post #13

Earlier quoted context omitted.

I've got to advise against Kibana/Elasticsearch until the company gets more mature. I was 100% on board with them up until the redesign. Not so much for the design (oh look it's white instead of black, who cares), but the way they've handled it subsequently. The 3.x -> 4.x transition for Kibana left a product that was missing really basic features (like, the ability to set graph colors for one - a bug/feature request…

Kibana 4.x is atrocious . In addition to generally being as heavy as a ton of bricks.

I've been using the latest Grafana release as an alternative to Kibana for visualizations. It now supports Elasticsearch as a db backend. Seems much faster and more stable than Kibana 4.

Re: Time series database Graphite seems to be falling into disfavor

#45

Post by chaotic-good »

gtrubetskoy wrote: post #4

I'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…

Can't agree more. Time-series data analysis should be considered the most important, not storage. Storage is a solved problem. Let's imagine that we're getting ECG data from many patients. What most time-series databases is able to do with this data? They can draw a nice graph. OK. They can resample this data. Well.. this is mostly meaningless for ECG. Can graphite/opentsdb/whatsoever find specific patterns indicating a disease (for example T-wave inversion)? No, but this is OK, because they're not designed for this. We should build new tools to solve new problems, not the old ones (like monitoring in DevOps).

Re: Time series database Graphite seems to be falling into disfavor

#46

Post by duaneb »

dmourati wrote: post #15

Obligatory response from Graphite contributor and author Jason Dixon who is shouted out in the vividcortex intro. http://obfuscurity.com/2015/11/Everybody-Loves-Graphite Personal response: I've used Graphite, OpenTSDB, Ganglia, Cacti, and a bunch more solutions. Recently, work transitioned from OpenTSDB to a hosted solution from a startup called Wavefront. https://www.wavefront.com/ This has been a smash hit. Scale m…

A closed silo seems like a distinct step backwards compared to a stack you can maintain yourself.

Re: Time series database Graphite seems to be falling into disfavor

#47

Post by sagichmal »

late2part wrote: post #8
discordianfish wrote: post #5

It 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.

OpenTSDB may be broken in the same way, but Prometheus isn't.

Re: Time series database Graphite seems to be falling into disfavor

#48

Post by duaneb »

yeukhon wrote: post #38

Graphite 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.…

The UI leaves a lot to be desired; there could be better tooling surrounding metrics selection (maybe like XPath?) for making rollup dashboards. Also, saving/editing the dashboard could use a better UI, but that's only like 10% of the time I put into the software.

Re: Time series database Graphite seems to be falling into disfavor

#49

Post by 5h »

sagichmal wrote: post #36
lumpypua wrote: post #12

What 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

> 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?
Post reply on HN