graphite-dev team mailing list archive

[Florin Andrei <question263398@xxxxxxxxxxxxxxxxxxxxx>]

New question #263398 on Graphite:
https://answers.launchpad.net/graphite/+question/263398

Previously, I've collected metrics via Sensu, using sensu-client as an agent, and sending the metrics into Graphite from sensu-server. What's great about it is that the Sensu plugins allow you to specify any arbitrary path for the metrics that are being collected. You could have a top level with each the VPCs in the cloud starting a different data tree, then instance groups on the next level within each tree, then instances on the next level. After the instances level you could have an "os" branch and an "app" branch. Below "os" you'd have "cpu", "mem", "disk", "net" and so on. Or just any scheme you might thing beneficial for your case.

In that setup, Graphite was tightly integrated with Sensu, and Sensu was doing all the hard work. The freedom to configure the data paths was awesome, but the whole system was complex. Sure, I was getting fault-detection and alerting for free, via Sensu, but this time around I got that part covered already.

Now I'm trying to deploy Graphite as a standalone metrics datastore. As an agent, I'm investigating collectd. It's easy to install and configure, and it seems to be able to collect high frequency data without any CPU load penalty. But there's one thing I don't like: the data paths for the metrics collected by the collectd plugins are more or less fixed. There's almost no freedom to change the structure of the branches.

Is there a way to munge those paths somehow before the metrics are dumped into Whisper? I still want to use collectd, if only there was a way to control those paths.

As a last resort, I might hack the source code, change the paths to the shape I need, and then rebuild the collectd packages, but I'd prefer to avoid that if possible.

-- 
You received this question notification because you are a member of
graphite-dev, which is an answer contact for Graphite.