3 ms·

Have you considered using any Graphite alternatives? I found it to be very slow with rendering data, especially when multiple arrays are being used as sources.

Have you considered using any Graphite alternatives? I found it to be very slow with rendering data, especially when multiple arrays are being used as sources. Also, it lacks some features that graphs rendering software is generally supposed to have, at least the half-a-year old version.

ralphm 13y ago
I did look at the greater landscape. What I found great about Graphite is the number of functions you have to massage the metrics. Not all metrics come in the same form (total number of bytes received since boot, or number of bytes received per second) and things like the `hitcount` and the `perSecond` (in the upcoming 0.10) functions really help. It can indeed be slow, and this is usually a I/O issue. The Whisper storage backend does a lot of seeks, and people recommend using SSDs to deal with that. Also, you can have graphite-web just give you the (calculated) metric data for a particular query in JSON, and have it rendered client-side. http://graphite.readthedocs.org/en/latest/tools.html http://graphite.readthedocs.org/en/latest/tools.html lists a few. Finally, we are investigating other storage backends for more fault tolerance. Probably we'll settle on something based on Cassandra, like http://blueflood.io/ http://blueflood.io/.
- brasetvik 13y ago
  Have you looked into using Elasticsearch's date histograms as sources for Graphite-functions? Jordan Sissel wrote a short note about it over here: https://gist.github.com/jordansissel/3760225 https://gist.github.com/jordansissel/3760225 That'll obviously be very expensive when the resolution is very high, though.
  - ralphm 13y ago
    I missed that, but that looks pretty awesome. Thanks for sharing!
anko 13y ago
at my work we use custom javascript/php to render our graphs with d3.js. It works quite well - we have things like a live(ish) piechart oh the status codes of web requests in the last (hour/timeperiod). the upside is we have a dashboard that is tailored for our use case, the downside is it took a couple of days to get right.

ralphm 13y ago

I did look at the greater landscape. What I found great about Graphite is the number of functions you have to massage the metrics. Not all metrics come in the same form (total number of bytes received since boot, or number of bytes received per second) and things like the `hitcount` and the `perSecond` (in the upcoming 0.10) functions really help. It can indeed be slow, and this is usually a I/O issue. The Whisper storage backend does a lot of seeks, and people recommend using SSDs to deal with that. Also, you can have graphite-web just give you the (calculated) metric data for a particular query in JSON, and have it rendered client-side. http://graphite.readthedocs.org/en/latest/tools.html http://graphite.readthedocs.org/en/latest/tools.html lists a few. Finally, we are investigating other storage backends for more fault tolerance. Probably we'll settle on something based on Cassandra, like http://blueflood.io/ http://blueflood.io/.

brasetvik 13y ago
Have you looked into using Elasticsearch's date histograms as sources for Graphite-functions? Jordan Sissel wrote a short note about it over here: https://gist.github.com/jordansissel/3760225 https://gist.github.com/jordansissel/3760225 That'll obviously be very expensive when the resolution is very high, though.
- ralphm 13y ago
  I missed that, but that looks pretty awesome. Thanks for sharing!

anko 13y ago

at my work we use custom javascript/php to render our graphs with d3.js. It works quite well - we have things like a live(ish) piechart oh the status codes of web requests in the last (hour/timeperiod). the upside is we have a dashboard that is tailored for our use case, the downside is it took a couple of days to get right.