google有四个黄金信号，分别是
Latency — The time it takes to service a request | |
| Traffic — A measure of how much demand is being placed on your system |
| Errors — The rate of requests that fail |
| Saturation — How “full” your service is. |
但可以先不翻译，也先不说这四个东西，先第一性想一下，一个业务系统，由一大堆计算机组成包括组成计算机的网络。然后这个系统一定有它的特点，要么计算密集型(图像计算)，要么io密集型(web)，要么吃内存(缓存服务器)，要么吃磁盘(文件存储)，要么需要高IO(数据库)，所以对这个系统的访问和资源占用就不同。
但我们可以抽象出四个维度的描述，
1，无论什么业务，时间是永恒的，都得有个时间出个结果的概念吧，所以叫响应时间也好，叫延迟也好，叫latency也好，反正就是多长时间出结果。
2，一共有多少量过来，系统是为业务服务的，那业务就有它的业务量，图像计算来说有多少图片过来计算，对于web来说有多少pv，对于缓存服务器来说有多少cache数据需要缓存，对于对象存储来说有多少文件需要存储，对于数据库来说有多少事务处理了。就是说每个业务系统有它自己的请求量的度量，就吞吐量，叫qps，就请求量，叫traffic都可以。
3，系统不肯能不出错吧，那出错了的请求量比例是多少？出错了的请求的响应时间是多少？
4，系统跑起来，总得占计算机资源吧，而资源是固定的，比如一个集群确定了，那它的cpu，内存，磁盘，网络就确定了。比如什么型号的cpu有几个，什么型号的内存有几条一共有多大，什么型号的磁盘，多大的网卡。那么它们有没有跑满，还有没有空闲，叫饱和度也好，叫利用率也好，总之还有没有资源？跑没跑满？
所以traffic，latency，errors，saturation总的来说就是，系统是什么业务类型的系统，目前有多少业务量，这个业务量下每个成功请求的响应时间是多少，这个业务量下每个错误请求的响应时间是多少，这个业务量下有多少比例的请求量是错误的，多少比例是成功的，这些业务量占用了多少资源。
一个系统的吞吐量(承压能力)与request(请求)对cpu的消耗，外部接口，IO等等紧密关联。 | |
| 单个request 对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高。 |
在应用场景访问压力下，只要某一项达到系统最高值， | |
| 系统吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换，内存等等其他消耗导致系统性能下降。 |
