At the moment main.go provides a simple way of getting started just by passing a metric name. As more inputs/analyzers/outputs are added, this will be changed to provide an interactive demo/tutorial for exploring data.

Which leaves the question of how a user configures anode (running as a service) to wire up different plugins to form processing pipelines.

Heka's approach is to use toml, with named sections for each plugin. So anode's version might look like:

[Input]
type = "graphite_input"
metric = "app.latency"
tag = "app.latency"

[Analyzer]
type = "three_sigma"
tag = "app.latency"

[Output]
type = "graphite_output"
tag = "app.latency"
prefix = "anode.three_sigma"

The config file parser can then initialize each plugin with the config given and wire together pipelines based on the tag.

But pipelines are graphs, and there are already DSLs for describing graphs, like DOT:

digraph LatencyPipeline {
  graphite_input [metric = "app.latency"]; /* declare node */
  graphite_input -> three_sigma; /* declare edge and node with default config */
  graphite_output [prefix = "anode.three_sigma"];
  three_sigma -> graphite_output;
}

Support for arbitrary config keys would be required so it may be beyond the capabilities of DOT, but it's a reasonable starting point.

Suggestions and links to prior art welcome.