I don't know if you've done this anywhere, but have you created any guidelines on tuning Influx based on workload?
We took a look at it last year, looked fantastic until we actually gave it more than a couple of metrics - and then it crashed and burned in so many ways. I tried fiddling with sharding and replication with no great success.
This was just before you were planning to get rid of the manual configuration for these things - so perhaps it's improved since then.
Having some idea of "If you want to store {X} metrics with {Y} updates per second for {Z} time, then you'll need at least this hardware configuration" would be great.
As it is, we've stuck with graphite, and we're kinda waiting for you guys to go past 1.0.
We don't have those recommendations at the moment. We'll be putting that out over the next few months after we release 0.9.0 and some point releases after that.
Out of curiosity, how many metrics are you tracking in Graphite? What's your sampling interval?
That should be doable if you're batching data together. The next build will actually do this automatically for you if you're writing into the Graphite, CollectD, or UDP inputs. It buffers some updates in memory to batch them in a single write to the underlying storage.
Might be worth another look for you when 0.9.0 comes out :)
We took a look at it last year, looked fantastic until we actually gave it more than a couple of metrics - and then it crashed and burned in so many ways. I tried fiddling with sharding and replication with no great success.
This was just before you were planning to get rid of the manual configuration for these things - so perhaps it's improved since then.
Having some idea of "If you want to store {X} metrics with {Y} updates per second for {Z} time, then you'll need at least this hardware configuration" would be great.
As it is, we've stuck with graphite, and we're kinda waiting for you guys to go past 1.0.