4 ms·

This post it's quite old and graphite ecosystem improve, some examples: Grafana from my POV is the best dashboard at the moment: http://grafana.org/ http://gr

This post it's quite old and graphite ecosystem improve, some examples: Grafana from my POV is the best dashboard at the moment: http://grafana.org/ http://grafana.org/ http://grafana.org/blog/2014/05/25/monitorama-video-and-update.html http://grafana.org/blog/2014/05/25/monitorama-video-and-upda... http://play.grafana.org/ http://play.grafana.org/ About alert system I'm using cabot: http://cabotapp.com/ http://cabotapp.com/ About system metrics, at the moment I'm using Diamond. https://github.com/BrightcoveOS/Diamond https://github.com/BrightcoveOS/Diamond In the other hand, Influxdb is growing, maybe I'll switch to InfluxDB next year, some features are better than graphite, and it's statsd compatible ;-) http://influxdb.com/ http://influxdb.com/ Regards ;-)

Shish2k 12y ago
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).
- pauldix 12y ago
  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_enhancements_in_0_9_0.html http://influxdb.com/blog/2014/12/08/clustering_tags_and_enha... [2] - https://github.com/influxdb/influxdb/blob/master/QUERIES.md#list https://github.com/influxdb/influxdb/blob/master/QUERIES.md#...
- the_vincedent 12y ago
  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.
- jmelloy 12y ago
  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.
- brunoqc 12y ago
  Is there a workaround to get a moving average?
sciurus 12y ago
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 https://github.com/pyr/cyanite [1] http://influxdb.com http://influxdb.com [2] https://github.com/brutasse/graphite-api https://github.com/brutasse/graphite-api [3] https://github.com/brutasse/graphite-cyanite https://github.com/brutasse/graphite-cyanite [4] https://github.com/vimeo/graphite-influxdb https://github.com/vimeo/graphite-influxdb [5] http://grafana.org http://grafana.org
- gingerlime 12y ago
  any idea what happened to the project that resulted in this halt?
  - jmelloy 12y ago
    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.
    - gingerlime 12y ago
      Surprising that with quite a few core contributors and (as far as I'm aware) pretty good adoption nobody picked it up though...
- samstave 12y ago
  Any idea on the performance of InfluxDB, I want to log ~500GB per hour in a timeseries DB. Can influx DB handle that?
llama052 12y ago
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.
- choffman 12y ago
  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.
- fizx 12y ago
  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)

Shish2k 12y ago

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

pauldix 12y ago
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_enhancements_in_0_9_0.html http://influxdb.com/blog/2014/12/08/clustering_tags_and_enha... [2] - https://github.com/influxdb/influxdb/blob/master/QUERIES.md#list https://github.com/influxdb/influxdb/blob/master/QUERIES.md#...
the_vincedent 12y ago
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.
jmelloy 12y ago
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.
brunoqc 12y ago
Is there a workaround to get a moving average?

sciurus 12y ago

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 https://github.com/pyr/cyanite [1] http://influxdb.com http://influxdb.com [2] https://github.com/brutasse/graphite-api https://github.com/brutasse/graphite-api [3] https://github.com/brutasse/graphite-cyanite https://github.com/brutasse/graphite-cyanite [4] https://github.com/vimeo/graphite-influxdb https://github.com/vimeo/graphite-influxdb [5] http://grafana.org http://grafana.org

gingerlime 12y ago
any idea what happened to the project that resulted in this halt?
- jmelloy 12y ago
  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.
  - gingerlime 12y ago
    Surprising that with quite a few core contributors and (as far as I'm aware) pretty good adoption nobody picked it up though...
samstave 12y ago
Any idea on the performance of InfluxDB, I want to log ~500GB per hour in a timeseries DB. Can influx DB handle that?

llama052 12y ago

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.

choffman 12y ago
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.
fizx 12y ago
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)