A README would be nice

[drawks]

Hey this looks like a sweet project. I had been toying with the idea of writing a go implementation of carbon-cache and this appears to be just that. It'd be nice if your project had some minimal amount of documentation that spelled out the scope and function to help surface it a little bit.

[dgryski]

I'll write some docs for this and the related carbonzipper project tomorrow.

[grobian]

@dgryski: cool @drawks: carbonserver only handles the http find and render requests (read part done by the web-api), it doesn't do updating of whisper files with new data. If you intend to do the latter, let me know, it would be replacing one of the two remaining original python-based components in our Graphite stack, which we're interested in for the matter of understanding and performance.

[drawks]

@grobian yeah I read through the code a bit more after posting the above comment. I very well might tackle the actual metric listener/writer portion of carbon. Actually I think that separating concerns between reading and writing could be interesting except that your fetch interface would then lose visibility of metric which aren't yet committed to disk.

Unfortunately I'm still a bit green at go and still learning the ropes of what a normal project looks like. Also after having much experience with the graphite/carbon codebase I really feel like I need to have a good handle on testing methodology in go before tackling this.

[grobian]

Interestingly enough, we noticed the cache port was never used, and since we don't use the cache part of the carbon store processes, we actually see /more/ up-to-date data than we saw when using the web-api (probably because the load drastically came down). We don't really care about the "cache" of the writer, at the moment. It probably complicates stuff more than is necessary if the disk subsystem can handle the load. If it can't handle the load, in our setup it's going to fail anyway, since our load is fairly constant so there would be no time to catch up.

We would need the current approach for our archive boxes (where no carbon-cache.py runs), but I could imagine a version/other program that does storing of data as well, that exposes the data like carbonserver does, but using its internal buffers and routines.