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

Graphite support #3964

Merged
merged 2 commits into from
Apr 25, 2017
Merged

Graphite support #3964

merged 2 commits into from
Apr 25, 2017

Conversation

hexylena
Copy link
Member

@hexylena hexylena commented Apr 24, 2017

Basically a complete copy+paste of statsd. Just grepped for statsd and copied over.

Visualised in Grafana
utvalg_038

@dannon
Copy link
Member

dannon commented Apr 24, 2017

Guess I don't see any harm here, but isn't it pretty much recommended to always aggregate at the statsd layer prior to graphite/graphana/whatever first?

We actually had, for usegalaxy.org, statsd->graphite at first, but are now using statsd->influxdb->grafana for a similar display.

@martenson
Copy link
Member

I would very much like to see some admin docs here how to set this up and why. It might be trivial for us but we should be building this for others.

@hexylena
Copy link
Member Author

hexylena commented Apr 24, 2017

We actually had, for usegalaxy.org, statsd->graphite at first, but are now using statsd->influxdb->grafana for a similar display.

We're using the graphite-influxdb interface. It's a bit of work to reconfigure influxdb due to our deployment choices, so this was the easiest method for us.

@hexylena
Copy link
Member Author

hexylena commented Apr 24, 2017

@martenson not sure how much there is to document. What would you want to see? I would guess that most people who use this are people who already know what graphite/statsd/etc are and are using it elsewhere.

The galaxy side setup is literally just filling out these vars. Setting up graphite/statsd/influxdb/etc are really probably outside the scope of possible docs.

@martenson
Copy link
Member

@erasche I guess in this case your explanation makes sense. But having an (short) admin page about options and config values to change if you want to track performance of your instance is something I would applaud to.

@hexylena hexylena mentioned this pull request Apr 24, 2017
@hexylena
Copy link
Member Author

@martenson #3968

@hexylena
Copy link
Member Author

Side note, would you be willing to share any grafana dashboard you have built? I, and the community, I'm sure would love to see what metrics you all find important to monitor.

@martenson
Copy link
Member

@erasche We do not have anything too useful at our instance yet. It has been deployed when we had UI slowness on Main to track it down, but we figured it out before grafana started to have data. And then it was down for a while so it has no data now I think. :/

@dannon
Copy link
Member

dannon commented Apr 25, 2017

@martenson That's incorrect, it has (lots of) data. We just need to figure out what we need to track want to render.

@dannon
Copy link
Member

dannon commented Apr 25, 2017

@erasche it's an item on our roadmap (#1928) to figure out what timings we care about, build dashboards, etc. Happy to work with you on that and share whatever we come up with, of course.

@martenson
Copy link
Member

@dannon That is great news! I was under the impression that we lost the data in the downtime.

@martenson
Copy link
Member

martenson commented Apr 25, 2017

I did not set up a graphite/carbon server to test this live, but code is short and looks solid. Thanks @erasche

@martenson martenson merged commit b9effa4 into galaxyproject:dev Apr 25, 2017
@hexylena hexylena deleted the graphite branch August 21, 2017 12:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants