当你操作你自己的基础架构时，你会有许多测量当前容量的方法。有测量历史数据和趋势的度量指标收集工具，监控关键的阀值变化的工具，当然还有解决ad-hoc故障检修的操作系统层的工具。这些都是我们在这本书里所提到过的。

因为在很多方面，云计算基础架构是一个“黑盒子”，并且大部分云服务提供商可供选择资源清单有限。所以，有效测量的重要性就变得更加显而易见了。尽管利用云服务可以使得部署周期显著缩短，你仍然要重视其余的容量规划过程。找出资源上限仍然是必须的，增长前部署新的实例也同样重要。

在存储的消耗方面，你可以把该项预测转移到你的云服务供应商,他们的职责就是保持在那条曲线的前方。然而，在计算实例方面，你从它们中获得的实际的工作量更大程度上依靠的是实例的大小或者等级，还有你的资源利用率（当然，是把实例的大小或者等级考虑在内的）。

除了测量你的云容量的这些普通理由，还有其他安装度量指标收集和适当的事件通知的一些原因：

•云服务供应商通过搅乱四周的容量来重新平衡架构，并达到处理增长的负载的目的，这也使得你的任何实例和存储的性能变化多端。

•即使你的云服务供应商有适当的服务等级协议，了解你的实例或者存储何时出故障 还是很重要的。一个好的经验就是：相信基础架构是可用的，但是这需要你自己进行验证。

•新容量的快速部署可以非常快，但不是瞬间即可。测量需要多久来发布一个新的实 例是值得的。

•尽管云存储量会因磁盘消耗而自动减少，但是你没法保证你能多快从那个存储重 新找回数据。就如第3章里的受磁盘的输入/输出限制的数据库，存储吞吐量是容量的一个因素，所以需要测量。同样，你的任何计算节点会受本地存储输入/输出限制。

就大部分的云服务供应商而言，你可能并不清楚你被分派的实例是如何运行的（或者在哪里运行的）。它们可能正在一个全新的硬件上运行。它们可能和其他有不断变动容量需要的虚拟实例一块分享硬件资源。它们可能被分配在一个利用率接近其极限的网络交换机上。在向持久存储中保存或者寻找数据时，你的实例或许会有（也可能没有）一致的延迟。在你的云服务供应商提供的接口覆盖下，你甚至不知道任何物理细节。

透明度的缺失带来了一些优势。它使得云服务供应商可以进行自由的维护操作（这使得新实例的快速供应成为可能）。这也使得客户不需要太关注容量缩减方面的本质细节。但是这也意味着你不能获得你所希望的所有详细资料，尤其当你习惯了手头拥有每一个详细资料时。