[noahnoahnoah]

This looks fantastic. From the short demo, nice UI for setting up charts, and the visualizations produced are quite nice as well.

The only downside to something like this (and Graphite, etc.) is that you can only visualize data that you store in Cube (if I understand correctly). That's great for things you sample yourself, but what if you want to compare something you sampled yourself with something from New Relic or another data source? Cube looks to go a step further than Graphite in allowing for easier custom visualizations, but data is still a one-size-fits-all thing. You can write an emitter/parser that grabs the data and stores it in Cube, but there's a huge amount of duplication (and essentially polling then).

I think a better architecture is to separate data storage/acquisition from visualization. Establish a set of standards for data interfaces that specify the output they provide, and build your visualization on top of that. Then, your interfaces can be API wrappers, mysql connections, a mongo-db based storage system, a redis-backed storage system, etc.

[mbostock]

True, but collecting the data into a single store makes it easier to analyze. If you want to construct visualizations (or perform analysis) with data from different back-ends, you can do that using Cube’s API. I do like your idea of establishing standards for data interfaces, but I wonder how hard it would be to put into practice.

[ojilles]

Doesnt that not simply already exist with RRDTool?