Frontend generated node charts with graphite as backend

[mruettgers]

Demo:
http://map.freifunk-aachen.de/dev/

[jplitza]

I love the feature in general and haven't looked too deep into the code right now. But one thing already strikes me: The data lines that can be drawn appear to be hardcoded (in charts.js lines 34–50), which really should not be the case. It is the community's decision which data they want to collect and plot. This could mean that they do not collect some data you want to plot there, or they collect other data and want that to be plotted.

[mruettgers]

I totally agree and it was configurable before, when the config file was a javascript file where I was able to deal with format-callbacks depending on the defined zoom levels and metrics.
I suggest to pre-define a number of available metrics and let the user select them in the config file along with other settings (color, name).

[mruettgers]

Metrics are now configured based on config.json

[tcatm]

What's the "id_to_mac" quirk for?

[mruettgers]

Sorry, this was just a workaround for our graphite setup that I forgot to remove.
We still need this workaround, because we started to record the stats based on the MAC-Address before the node ID had been introduced in ffmap-backend.
All it does is to add the colons to the node ID, but as already said, this shouldn't be in the code for future use.

[genofire]

What would be used for future use? - would it be merge in nearer future.
It would be nice, so i could extend it for influxdb, too :)

[tcatm]

I think what is missing here is documentation on how to setup the backend for this. Then I could test this. I've also seen Prometheus being used for gluon-collector. We should probably settle on one solution and document how both the backend and the frontend needs to be configured for this to work.

[mruettgers]

I did some work on the backend setup a couple of months ago (https://github.com/ffnord/ffmap-backend/tree/dev#graphite-support).
But because we are testing hopglass-server (with graphite + influxdb) at the moment, there's not much progress on this, but it should play well with the statistics feature.
I'd love to see multiple backend support in gluon-collector, ffmap-backend, hopglass-server and the frontend part :-).

We use influxdb as datasource for grafana (Examples: http://ffac-monit.skydisc.net:3000/dashboard/db/overall), but I can't say what's the best backend for our case.

[genofire]

@mruettgers so you will make influxdb compatible on your own or make this to a merge able version?
(Or just throw it away :( )
It would be sad if this PR would never merged