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:
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 <firstname.lastname@example.org> wrote:
Interested why you use InfluxDB over Graphite - any information on that?