Very cool service!<p>Question about the architecture though: what were the reasons for using HTTP as opposed to UDP (which is typically how these stats collection servers receive data)? It looks like it's possible to keep system load manageable since you aggregate the data and space out the HTTP requests, but why do this instead of just blasting the server with UDP requests?
Some time ago I wrote a system to collect performace statistics for my company's internal use (we have 100+ application servers - 4-6core 2xcpu hardware servers - and 1 server running the statistics). And then we released it as open-source.
Our system shows not only by-service- or by-source-script- statistics, but also which services are used by a particular script.
Drawback: all information is in russian.<p>pics: <a href="http://imgur.com/a/idFF6" rel="nofollow">http://imgur.com/a/idFF6</a>
<a href="https://github.com/mambaru/btp-daemon" rel="nofollow">https://github.com/mambaru/btp-daemon</a> - and google-translated text <a href="https://gist.github.com/3139890" rel="nofollow">https://gist.github.com/3139890</a><p>Anyone interested? Is it worth to translate it to english?
Does the name mean anything? I guess it's an anagram of statsd, but it's tough on the eyes.<p>Maybe I'm just not seeing them, but this seems to be missing some of my favorite graphite features.<p>- Combining multiple metrics on a single graph<p>- Filters (e.g. lowestCurrent)<p>- Graph labels and resizing<p>Is there a feature like graphite events?
Sorry to be that guy, but I don't like linkbait headlines.<p>If you spend a lot of work then perhaps you <i>might</i> be a "replacement for graphite" in about 1 year.<p>Today you're barely a prototype.
Do you support aggregating the data and showing graphs for percentiles? So I'd like to send you latency stats and then get a graph for latency at the 99th percentile (or 90th percentile) or whatever.
Oh come on man, don't tell me it's free. Tell me what numbers I can go up to before you give me the "phone call" (if that, you could go Google and just shut stuff off without any notification or warning of any kind) telling me I've hit some sort of API limit.<p>The ambiguity is like that Oracle Linux debacle.<p>I don't even really care if you intend on living in fantasy-land and never intend on charging for the service (get real), at least give me some idea of what the limitations are.<p>I like the live demo though, good idea.<p>I <i>want</i> to use your service but you need to set up some clearly defined boundaries. I'm not some sort of enterprise-wonk trying to hold you to an uptime contract, I'm a startup guy trying to make certain he's not hinging stuff his company uses on something overly uncertain.