Hi,
I’m looking at starting to use graphite for graphing metrics.
Anyone got any information, or pointers to write ups on using collectd -> graphite vs sensu metrics?
Is it just a case of using sensu you’re utilising the sensu_client which is already running rather than running another process - or are there other advantages?
Thanks,
Ian
Sensu metric checks do not scale as nicely. The more metrics you collect the more processes get spawned. You can try to use extensions to alleviate that, but IMO tools like collectd or telegraf are better suited for high granularity metric collection. They are very lightweight and easy to deploy. Both collectd and telegraf can push to graphite AFAIR. I personally use native InfluxDB with telegraf and I’ve been very happy with that choice.
On Tue, Apr 11, 2017 at 1:42 PM, Ian Chilton ian.chilton@gmail.com wrote:
Hi,
I’m looking at starting to use graphite for graphing metrics.
Anyone got any information, or pointers to write ups on using collectd → graphite vs sensu metrics?
Is it just a case of using sensu you’re utilising the sensu_client which is already running rather than running another process - or are there other advantages?
Thanks,
Ian
Interesting, thanks!
Interested why you use InfluxDB over Graphite - any information on that?
Thanks!
Ian
On Tuesday, 11 April 2017 18:58:39 UTC+1, Moises Silva wrote:
Sensu metric checks do not scale as nicely. The more metrics you collect the more processes get spawned. You can try to use extensions to alleviate that, but IMO tools like collectd or telegraf are better suited for high granularity metric collection. They are very lightweight and easy to deploy. Both collectd and telegraf can push to graphite AFAIR. I personally use native InfluxDB with telegraf and I’ve been very happy with that choice.
You can google 'influxdb vs graphite' for several interesting blog posts.
Personally, the tooling of influxdb (its command line for example), the
nice query language, simplicity of deployment (go, single binary) and the
data model (what now days ppl call multi dimensional) that allows tagging
metrics which allows more powerful queries made it a better option. If you
want more info on what this 'multi dimensional' data model means, read here:
http://www.boxever.com/the-power-of-multi-dimensional-labels-in-prometheus/
That's a Prometheus (another time series db and monitoring project) blog
post, but the concept of labels is the same as 'tags' in InfluxDB, which
graphite doesn't have (it encodes the info in the metric name).
Keep in mind Graphite has some things going on like simplicity of data
aggregation (so older data goes into lower resolution db). With influx you
need to write CQ (continuous queries), so the metric aggregation is a bit
more manual (read more config/work). They're working on something automatic
but I've not looked at it. Having said that, If you have enough storage or
not many hosts you can stick to a single retention policy and avoid
writing/running CQ's for aggregation.
On Tue, Apr 11, 2017 at 4:49 PM, Ian Chilton <ian.chilton@gmail.com> wrote:
Interesting, thanks!
Interested why you use InfluxDB over Graphite - any information on that?
Interesting, thanks!
On Wednesday, 12 April 2017 00:23:22 UTC+1, Moises Silva wrote:
On Tue, Apr 11, 2017 at 4:49 PM, Ian Chilton ian.c...@gmail.com wrote:
Interested why you use InfluxDB over Graphite - any information on that?
You can google ‘influxdb vs graphite’ for several interesting blog posts. Personally, the tooling of influxdb (its command line for example), the nice query language, simplicity of deployment (go, single binary) and the data model (what now days ppl call multi dimensional) that allows tagging metrics which allows more powerful queries made it a better option. If you want more info on what this ‘multi dimensional’ data model means, read here:
http://www.boxever.com/the-power-of-multi-dimensional-labels-in-prometheus/
That’s a Prometheus (another time series db and monitoring project) blog post, but the concept of labels is the same as ‘tags’ in InfluxDB, which graphite doesn’t have (it encodes the info in the metric name).
Keep in mind Graphite has some things going on like simplicity of data aggregation (so older data goes into lower resolution db). With influx you need to write CQ (continuous queries), so the metric aggregation is a bit more manual (read more config/work). They’re working on something automatic but I’ve not looked at it. Having said that, If you have enough storage or not many hosts you can stick to a single retention policy and avoid writing/running CQ’s for aggregation.