The thing that's missing from this article (which is relevant to this crowd) is the incredible focus on simplicity of Keen's API. Keen's API for reporting metrics is the right one. Any Keen SDK has essentially one API call for reporting metrics:<p><pre><code> keen.add_event("collection_name", {
"arbitrary": "dictionary properties",
"with_any_type": -11.23
})
</code></pre>
For developers accustomed to instrumenting their applications with various metrics libraries, this is akin to finding the holy grail. Most APIs for metrics collection require you to decide up front what metrics you want, whether it is a time series or a count or a gauge or a ratio. And even after you've figured _that_ out, there is a combinatorial explosion of different metric collections you have to create for every combination of filters that interest you.<p>For the developer, Keen's API is so powerful because it lets you defer almost all of your "question-asking" until later (which is when you want to think about it anyways because you can never predict up front all of the questions you want to ask about your data).<p>When I began to evaluate options for monitoring ngrok's usage and performance, Keen struck me both for getting the abstraction right, and because I have watched company after company dump countless amounts of money and developer time into homegrown analytics systems that materialize either too late or far over budget.<p>Disclaimers:<p>- I am Keen customer for ngrok.com (<a href="https://ngrok.com/status" rel="nofollow">https://ngrok.com/status</a>)<p>- Compelled by the power of their product, and the competence of their team, I now work for Keen.