Why we migrated away from Librato to InfluxDB?(zemanta.github.io) |
Why we migrated away from Librato to InfluxDB?(zemanta.github.io) |
- 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...
- 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.
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.