正文
错误率（errors），例如每秒失败的请求数，或者错误率（error ratio），失败的请求占总请求数的比例。
饱和度（saturation），或者叫使用率（utilization），指的是系统的“热度”，数字越高，系统越热，通常延迟也会随之加大。通常是个百分比（0~100 算正常，高于 100 算过载），等于当前资源使用量除以资源配额。对于请求响应式的服务，utilization 大体正比于流量，当 utilization 达到 100 时的流量即是系统的容量（capacity）。
这些监控指标适用不同的聚合算法，用错了聚合算法会得到错误的汇总数据，简单的说是平均和加权平均的区别。
采集数据
服务进程通过某种方式暴露一些内部指标（metrics），然后监控程序会定期（比如 1 分钟）采集所有服务进程的 metrics，采集得到的数据都有时间戳。所谓“聚合”，就是根据 serving tasks 的原始数据算出那个 serving job 的数据，最简单的例子：知道每个 task 的流量，那么 job 的流量是 tasks 流量之和。
这里有两点值得注意：
-
服务器应该暴露原始计数值，而不是其导数。比如服务进程有一个 int64_t requests，记录从启动到现在一共响应了多少个请求，服务进程每收到一个请求就把 requests 递增1。这个 requests 要暴露给监控系统，监控系统会定期采集这个数值，存到时间序列 task:requests 中。当然，服务进程重启的话，requests 会归零，监控系统应该对此有准备。服务器不需要对监控系统暴露“过去一秒钟内服务了多少个请求”。
-
采样率。采样率太低的话，一些尖峰就被平滑掉了。举个例子，假如负载均衡的反馈控制回路（feedback loop）陷入了振荡（oscillation），系统的流量以较短的周期剧烈波动，而振荡周期小于监控系统的采样周期，那么从监控的流量图上是看不出振荡的，还以为系统运行平稳，而实际上系统在每个振荡周期的流量波峰都处于超载状态，使得错误率攀升。根据
Nyquist 采样定理
，监控系统的采样率至少要大于振荡周期的 2 倍，才能从监控的时间序列图上看出振荡来。
定期采集几千上万个服务进程的指标不是一件轻松的活，监控系统本身的伸缩性也要够好，才能监控上千台机器上万个进程的 serving stack。第 10 章提到了 sharding 的办法，题图正是这一做法的示意。
三种数据类型
在讲数据聚合之前，先了解三种基本的数据类型，它们适用不同的聚合算法。这里我推荐先阅读
RRDtool
-
tutorial
，这算得上是监控的始祖。这篇 tutorial 介绍了 Counter 和 Gauge 这两种类型，其中 Counter 就是我们下文提到的 Rate，但漏掉了另一个重要的 Ratio 类型。
