**Four Golden Signals**是Google针对大量分布式监控的经验总结，其可以在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。主要关注与以下四种类型的指标：延迟、通讯量、错误以及饱和度
- 延迟：服务请求所需时间「Time」
记录用户所有请求所需的时间，重点是要区分_成功请求_的延迟时间和_失败请求_的延迟时间。。例如在数据库或者其他关键祸端服务异常触发HTTP 500的情况下，用户也可能会很快得到请求失败的响应内容，如果不加区分计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。在微服务中通常提倡“**快速失败**”，开发人员需要特别注意这些延迟较大的错误，因为这些缓慢的错误会明显影响系统的性能，因此追踪这些错误的延迟也是非常重要的
- 通讯量：监控当前系统的流量，用于衡量服务的容量需求「PV」
流量对于不同类型的系统而言可能代表不同的含义。例如，在HTTP REST API中, 流量通常是每秒HTTP请求数
- 错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率「Error」
对于失败而言有些是显式的(HTTP 500错误)，而有些是隐式(HTTP响应200，但实际业务流程依然是失败的)。对于一些显式的错误如HTTP 500可以通过在负载均衡器(如Nginx)上进行捕获，而对于一些系统内部的异常，则可能需要直接从服务中添加钩子统计并进行获取
- 饱和度：衡量当前服务的饱和度「Load」
主要强调最能影响服务状态的受限制的资源。 例如，如果系统主要受内存影响，那就主要关注系统的内存状态，如果系统主要受限与磁盘I/O，那就主要观测磁盘I/O的状态。因为通常情况下，当这些资源达到饱和后，服务的性能会明显下降。同时还可以利用饱和度对系统做出预测，如，“磁盘是否可能在4个小时候就满了”
常规的监控指标整理
监控可以分为“黑盒监控”与“白盒监控”，黑盒监控解决的是“_系统哪些功能出了问题”_，白盒监控解决的问题是“_什么原因导致了上述故障_”
-
所有系统和第三方依赖的核心功能必须添加黑盒监控
-
所有模块必须添加白盒监控的四个黄金指标（饱和度，错误，流量和延时）
-
所有的变更都需要进行采集，包括但不限于程序，配置，数据，网络，硬件，操作系统以及各类基础设施
业务监控：从客户角度评估业务状态
主要是与用户、与业务相关的一些监控，属于功能层面的，大多数是项目经理或产品经理会比较关注的对象
应用监控：从应用层面反应系统的状态
指的是服务角度的监控，比如接口、框架、某个服务的健康状态等，一般是服务开发或框架开发人员关注的对象
- 接口
包括服务实例处理请求的情况及实例调用其它服务的情况，具体而言包括请求总数、请求处理时延（中位数，包括有 90、95 和 99 值）、请求结果（成功、失败、熔断、限流、超时和拒绝）统计、调用其它服务的结果（成功、失败、熔断、限流、超时和拒绝）统计及时延（中位数，包括有 90、95 和 99 值）
- 异步任务/消息
- 任务总运行次数
- 任务成功/失败运行次数
- 任务的运行时长
- 任务/消息从生成到执行的时间间隔
