-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Statsd/Graphite Support #724
Comments
Thanks for filing the issue, @rosskukulinski Do you collect any container data in statsd today? What's the preferred metric format for statsd cadvisor.. ( we can remove cadvisor from the name if that's not useful). We don't know much about statsd. Are there any restrictions on character sets that can go in the metric name? Is "cadvisor./.cpu_usage" a valid name? |
We aren't sending any container data to statsd currently. We briefly played with some collectd plugins that supposedly get cgroup data and pipe it to graphite directly -- but were not successful in a quick test. Some background on statsd: Statsd is actually a pretty simple nodejs metric aggregation daemon. It listens for udp or tcp messages of the format: Statsd receives and aggregates metrics before sending them to a storage backend like graphite. Graphite has been around for a long time - it provides metric storage and graph rendering and supports clustering natively. Statsd does have a number of 3rd party backends as well. I do not believe you can use slashes in the metric name as Whisper (graphite's underlying storage mechanism) uses the filesystem. Quick googling has confirmed this. We replace the slashes in all of our HTTP metrics with underscores before sending to statsd. |
Hi, I just finish a statsd storage for cadvisor, if you wish try it and send me some feedback about how I did it, you can test it by running my docker image jmaitrehenry/cadvisor or by checking the PR #798 This is how I run it:
With storage_driver_db is use as a prefix for all stats, I use it for prefixing stats with the docker node hostname for example. This is a sample of gauge receive by statsd :
|
Amazing! I'll try to find some time and take this for a spin tomorrow On Sunday, July 5, 2015, Julien Maitrehenry notifications@github.com
|
Works great! The metrics paths are still a bit messy when forwarding them from statsd to graphite with whisper storage, but definitely useful. Might be worth to get aligned with #474... |
@schneidexe something like prefix.container_id.container_name.metric ? If you wish more metrics, I can do that in a new PR after this one will be merge without problem :) |
Statsd support is in. Remaining items:
|
any updates on this? I'd like to forward via graphite. It sounds like it might be possible now but i can't find any docs on it |
After @rjnagal pinged me on twitter, I figured I should open an issue here.
We're looking for a statsd (or pure graphite) metrics output like you've done with influxdb. While we love the direction influxdb is headed, we couldn't get it to scale as well as we have with statsd & graphite.
We would take a crack at implementing this, but we're not Go people, and are a bit pre-occupied shipping features to our users these days.
I don't know if this is something that's on your roadmap or not -- if it is, we'd happily help debug/test this feature.
The text was updated successfully, but these errors were encountered: