Part 1 http://www.jinspired.com/site/how-not-to-design-a-metrics-api-part-1-millions-of-metrics

“Millions of Metrics” is a statement made by Adrian Cockcroft, Cloud Architect @ Netflix, in discussing the monitoring of applications deployed using their own proprietary PaaS solution. Granted it’s somewhat boastful (he was speaking on stage) but to those not very well experienced in application performance monitoring it not only sounds impressive it sounds like a goal worth pursuing which would be a mistake. The problem with this unqualified statement is that it does not make the distinction between an information model and a management model, a measure and a metric, a measurement and a sample. There is no software, model, process or human that can effectively use, scale and benefit from a set of such size at least not from a management perspective. It would be terribly (cost) ineffective as the behavior of most applications and systems are driven (determined) and signaled (distinguished) by a very small number of measures.

Part 2 http://www.jinspired.com/site/how-not-to-design-a-metrics-api-part-2-delegation-separation

The single most important requirement for any Open API should be the ability to use an alternative implementation that adheres to the API contract whilst offering additional benefits over the default implementation in terms of performance, resource management, reliability, scalability, extensibility, serviceability, tooling, integration and so on. If you can’t switch to an entirely different implementation then it most certainly is not open, irrespective of the ability to access the source, and its debatable whether it really is an API (more so a library).