It's a brand new newsletter from two community menbers who also happen to be authors of two O'Reilly monitoring books, the creator of Monitorama, and a long-time maintainer of the Graphite project. You don't have to believe me but we're going to do our best to release a top-notch collection of monitoring-related stories. We don't have an archive yet but we intend to.
Nobody ever said it /can't/ be done. I would never have argued against using a real RDBMS. But I've often been guilty of telling folks that SQLite was "good enough".
Installing PostgreSQL as you described is not "good enough". If you're going to bother with that, you need to understand the database enough to tune it properly, setup backups, test restores, etc. There are more considerations than simply installing it from apt-get and then forgetting about it.
Except that while Graphite is a "real web application", it's generally internal-facing only. As such, I never looked at it as needing a true "production-ready" RDBMS with real concurrency. And to be honest, we got by just fine with it in production at Heroku and GitHub, at heavy volume, running in a single server on SQLite. It never bit us, and all things considered, was a reasonable choice.
That said, knowing what I know now, I would've never done that. ;-)
That's not at all a dumb comment. As I alluded to in the post, I think it's important that we understand how these systems determine what is - or isn't - an abnormality or fault. Unfortunately, that often means revealing their "secret sauce" and risk exposing their product differentiation. It's going to be interesting to see how these products earn our trust.
Yes, it certainly /can/ scale. In fact, a properly modularized monitoring solution /should/ be more capable of scaling if it was designed with this in mind. This is certainly the approach we've taken with our monitoring and trending components at Heroku. We don't have anywhere near 500K nodes, but the principles scale.
@josephruscio - I was >this< close to going back and giving a quick mention to Librato Metrics. You guys definitely "get" what I'm talking about. I like that you provide well-defined interfaces for easily getting data into and out of your application. You focus on trending and let other (better?) software handle the other stuff.
I think Pingdom applies to some extent. In particular because it allows you to get the raw data out which can then by imported into trending software or notification services elsewhere.
It seems to me that you're referring to a) other data outside of the scope of this example and b) the fact that Whisper uses average data for rollups. This is a valid issue and one of the reasons for the new Ceres format.
The metrics I demonstrate in the article do not rollup. If they did I'd completely lose the data. That's why I keep them at 1-sec resolution for their lifetime (generally 1 year). In hindsight it seems your original comment was a general critique of one aspect of Graphite and outside the scope of this particular article.
I don't follow. Graphite doesn't "throw anything away". You define your own retention policy and Graphite follows it. You're free to maintain 1-second resolution for 50 years, if you have the storage capacity for it. But that isn't what this article is about.
The example covers a particular metric use-case for annotation-style details, and how to extract a meaningful aggregate from what is otherwise contextual data. Personally I love that Graphite lets me "hack about" with multiple functions. But I'm a data whore, YMMV. ;-)
https://github.com/obfuscurity/synthesize/releases/tag/v3.0....