Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frontend generated node charts with graphite as backend #22

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

mruettgers
Copy link

@jplitza
Copy link
Member

jplitza commented Jan 14, 2016

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
Copy link
Author

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).

Let the user configure the metrics in config.json
@mruettgers
Copy link
Author

Metrics are now configured based on config.json

@tcatm
Copy link

tcatm commented Feb 12, 2016

What's the "id_to_mac" quirk for?

@mruettgers
Copy link
Author

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
Copy link

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
Copy link

tcatm commented Mar 19, 2016

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
Copy link
Author

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:https://ffac-monit.skydisc.net:3000/dashboard/db/overall), but I can't say what's the best backend for our case.

@genofire
Copy link

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants