Yes, you're totally right. You need more information than the Five Number Summary. You can turn two averages into an average if you have the number of original data points; and you can turn two stddevs into one if you have the averages and number of data points. But percentiles are a whole 'nother story. My suspicion is that Graphite's concept of percentiles is related to the data points it has stored. So it's not the 90th percentile *at that point*, but rather the 90th percentile of the data in the metric. To get 90th percentile at a given point in time, I would use statsd, which can calculate that and emit it to Graphite. So there's a percentile at a point in time, and then a percentile across all time (or across the last X data points). I suspect Graphite is doing the latter. Technically valid, but super duper confusing.

I haven't, yet. It seems like it would break existing use to make this change, even if it is to fix it. (Maybe people have come to expect derivative to be a delta between data points.) But maybe I should let them make that decision?

Hmm. I think the reason I exclude Facebook is that the newsfeed is status updates, activity updates, etc. Less about being a stream of your posts. Notes doesn't seem to be an often-used feature, and the status update box doesn't encourage long-form writing. So it's more geared towards "what's going on" rather than "what's on your mind". I think it has all the right features, but the emphasis is different.

Sylvain, that's something that I still need to explore more. The first idea that comes to mind is Nagios event handlers, where you can run scripts after certain soft/hard failures. I don't like that though, I wish there was a better way of triggering this, maybe from tools like Riemann or Jenkins?

The major assertion here is that application development teams are responsible for making sure their application is working properly, on all levels. Business data needs to be digested and managed in other ways (often not even time-series based), but application data often is chronological. But I think we are moving away from the idea that servers belong to one team, code belongs to another, and the business on top of it belongs to a third. The health of an application overall is owned by the development team. Who gets to resolve a problem might vary, sure, but every team needs to have a view into what's going on with their own application. (Some might even argue that they should be the front-line responders, carrying pagers, etc.) With this unified view, important stuff bubbles up to the top, and ideally allows you to understand what's broken and why -- whether or not it's in your control to fix. In that world, you actually spend a lot more time focusing on building the right alerts and making sure they go to the right people/places, because your system is smart enough to know who needs to know what, when, and to ask them to look at a simple view of the world.