I've been a graphite contributor for a while (and still am). It's a great tool for timeseries metrics. Two weeks ago I started working on Graphite-ng: it's somewhere between an early clone/rewrite, a redesign, and an experiment playground, written in Golang. The focus of my work so far is the API web server, which is a functioning prototype, it answers requests like
I.e. it lets you retrieve your timeseries, processed by function pipelines which are setup on the fly based on a spec in your http/rest arguments. Currently it only fetches metrics from text files but I'm working on decent metrics storage as well.
There's a few reasons why I decided to start a new project from scratch:
The API server I developed sets up a processing pipeline as directed by your query: every processing function runs in a goroutine
for concurrency and the metrics flow through using Go channels. It literally compiles a program and executes it. You can add your own functions
to collect, process, and return metrics by writing simple plugins.
As for timeseries storage, for now it uses simple text files, but I'm experimenting and thinking what would be the best metric store(s) that works on small scale (personal netbook install) to large scale ("I have millions of metrics that need to be distributed across nodes, the system should be HA and self-healing in failure scenarios, easily maintainable, and highly performant") and is still easy to deploy, configure and run. Candidates are whisper-go, kairosdb, my own elasticsearch experiment etc.
I won't implement rendering images, because I think client-side rendering using something like timeserieswidget is superior. I can also leave out events because anthracite already does that. There's a ton of dashboards out there (graph-explorer, descartes, etc) so that can be left out as well.
Posted by Jimmie on Sun Sep 8 17:08:31 2013
Posted by daledude on Mon Sep 9 01:44:51 2013
Posted by Alexander Zhuravlev on Wed Sep 11 17:52:30 2013
Posted by Dieter on Mon Sep 16 22:27:39 2013