4 ms·
We are in the final stages of the last 0.9.x release, 0.9.13. From then on, we're going to be making some more noticeable changes that break some backwards comp
by SEJeff 12y ago
We are in the final stages of the last 0.9.x release, 0.9.13. From then on, we're going to be making some more noticeable changes that break some backwards compat to make the project a lot more pleasant.
Note that 0.9.13 is almost ready to be cut:
https://github.com/graphite-project/graphite-web/commit/78629d4c811cf7994639dfb852b01d40af8293c3 https://github.com/graphite-project/graphite-web/commit/7862...
https://github.com/graphite-project/carbon/commit/e69e1eb59aaade325d37e68d920d786f280d294a https://github.com/graphite-project/carbon/commit/e69e1eb59a...
https://github.com/graphite-project/whisper/commit/19ab78ad6f4aa2c34d4bd5b84bf876ad5212bc64 https://github.com/graphite-project/whisper/commit/19ab78ad6...
Anything in the master branch is what will be in 0.10.0 when we're ready to cut that. I think we'll spend some more cycles in 0.10.x focusing on non-carbon / non-whisper / non-ceres backends that should allow much better scalability. Some of these include cassandra, riak, etc.
For it timing out, it is a matter of general sysadmin spleunking to figure out what is wrong. It could be IO on your carbon caches, or CPU in your render servers (where it uses cairo). I'm a HUGE fan of grafana for doing 100% of the dashboards and only using graphite-web to spit out json, or alternatively to use graphite-api.
Take a look at the maxDataPoints argument to see if that will help your graphs to not timeout however.
- mdeeks 12y agoMy brief experience with browser based rendering was not good. Our dashboard pages often have 40-50+ graphs for a single cluster. I found it brought all browsers to a crawl and turned our laptops into blazing infernos when viewing longer timelines. Granted I didn't try out graphana so it could have been related to badly optimized javascript in the ones I tried. CPU on the render servers is low. IO on the carbon caches is acceptable (10k IOPS on SSDs that support up to 30k or so). If the CPU Usage Type graph would render it would show very little IO Wait (~5%). Graphs if you're interested: http://i.imgur.com/dCrDynY.png http://i.imgur.com/dCrDynY.png Anyway thanks for the response. I'll keep digging. Looking forward to that 0.9.13 release!
- SEJeff 12y agomaxDataPoints was a feature added by the guy who wrote giraffe[1], which is for realtime dashboards from graphite. It was too slow until he added in the maxDataPoints feature, and now it is actually really awesome when setup properly. Also look at graphite-api[2], written by a very active graphite committer. It is api only (only json), but absolutely awesome stuff. Hook it up to grafana for a real winner. [1] http://giraffe.kenhub.com/#dashboard=Demo&timeFrame=1d http://giraffe.kenhub.com/#dashboard=Demo&timeFrame=1d [2] https://github.com/brutasse/graphite-api https://github.com/brutasse/graphite-api