
Why we migrated away from Librato to InfluxDB? - andraz
http://zemanta.github.io/2016/05/10/from-librato-to-influxdb/
======
josephruscio
A couple thoughts from a Librato founder here:

\- Appreciate the thorough and balanced approach you took here, there's a lot
of great feedback, most of which helps validate our current roadmap and 1-2
things we'll certainly consider.

\- The tradeoff of providing a true utility service where you only pay for
what you use is that the actual makeup of your bill can become complex (think
of your AWS bill). We do pro-rate usage to the hour right now (matching AWS),
so unless your metric "lifetimes" are sub-hour there's shouldn't be a huge
issue.

\- There's a similar power/complexity tradeoff with rollups. Unlike some
solutions that only rollup via average we track multiple summary statistics
e.g. min, max, sum, count, weighted average. Managing the differences between
these can be confusing in some cases, so we're currently working on a simpler
interface to toggle between these. More details can be found here:
[https://www.librato.com/docs/kb/visualize/faq/rollups_retent...](https://www.librato.com/docs/kb/visualize/faq/rollups_retention_resolution.html)

\- Mobile support is something we've been incrementally adding and will
continue until it's complete e.g. the actual alerts page you land on from a
notification is now mobile-ready.

\- Tagging. In the years since we first launched (when AFAIK only OpenTSDB
supported this) it's become clear that this is becoming more and more a
standard capability. Which is why we've been building out a next-generation
data-store, which supports indexed tagging and a bunch of other new
capabilities. We expect it to be in beta this summer.

~~~
tomazk
I'm really glad you've noticed this post and that librato will continue to
improve based on the feedback.

I hope my post will NOT get across as "picking librato in the first place was
a mistake", because we definitely don't regret starting with you guys. We were
up and running quickly with metrics and alerting in no time and we got to
learn how important it is to be able to filter metrics per host. We definitely
didn't had the time to set up everything by ourselves and your platform +
great support provided the right solution.

At the time, the alternative was to set up our own graphite and from my
experience, internal tools that you don't have time to _really_ invest in,
will break faster than you can think of. Having dealt with non-maintained,
internally owned self managed graphite+syren stack before, I have 0 regrets :)

But as we grew and InfluxDB matured, we've done a bit of research, discovered
cool features (e.g. tags) we can make great use of and later on decided to go
with managed InfluxDB solution and the ecosystem it brings along.

In the post I also argue that librato is a good pick, if you're a small team
with no ops people and need a metrics+alerting backend ASAP.

------
jacobriers
We went on the hunt for a time-series data-store a while ago and ended up
picking OpenTSDB. It seems they are planning on supporting Cassandra (which
sounds like it will be easier to maintain than HBase):
[http://opentsdb.net/docs/build/html/user_guide/backends/cass...](http://opentsdb.net/docs/build/html/user_guide/backends/cassandra.html)
Another worthy contender was KairosDB:
[https://kairosdb.github.io/](https://kairosdb.github.io/)

------
fenesiistvan
Can I ask, what tool have you used for the 3d charts?

~~~
hijinks
[https://cloudcraft.co/](https://cloudcraft.co/)

~~~
thom_nic
It looks very cool but it's terribly difficult to read.

------
Animats
How many transactions per second? Is all this really necessary?

------
igzebedze
excellent post

~~~
idioterna
i know this is just too easy now, but... we told you so :)

