??????????????什么是黄金信号指标？您如何监控 Kubernetes 应用程序中的黄金信号？Golden Signals 可以帮助您检测微服务应用程序中的问题。这些信号是一组简化的指标，从用户或消费者的角度提供服务的广泛视图，因此您可以检测可能直接影响应用程序行为的潜在问题。

 

 

监控所有

---

在之前Prometheus简介部分介绍监控的基本目标，首先是及时发现问题其次是要能够快速对问题进行定位。对于传统监控解决方案而言，用户看到的依然是一个黑盒，用户无法真正了解系统的真正的运行状态。因此Prometheus鼓励用户监控所有的东西。下面列举一些常用的监控维度。

 

 

监控模式

---

除了上述介绍的不同监控级别以外。实际上根据不同的系统类型和目标，这里还有一些通用的套路和模式可以使用。

 

 

4个黄金指标

---

Four Golden Signals是Google针对大量分布式监控的经验总结，4个黄金指标可以在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。主要关注与以下四种类型的指标：延迟，通讯量，错误以及饱和度：

• 延迟：服务请求所需时间。

记录用户所有请求所需的时间，重点是要区分成功请求的延迟时间和失败请求的延迟时间。 例如在数据库或者其他关键祸端服务异常触发HTTP 500的情况下，用户也可能会很快得到请求失败的响应内容，如果不加区分计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。除此以外，在微服务中通常提倡“快速失败”，开发人员需要特别注意这些延迟较大的错误，因为这些缓慢的错误会明显影响系统的性能，因此追踪这些错误的延迟也是非常重要的。

• 通讯量：监控当前系统的流量，用于衡量服务的容量需求。

流量对于不同类型的系统而言可能代表不同的含义。例如，在HTTP REST API中, 流量通常是每秒HTTP请求数。

• 错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率。

对于失败而言有些是显式的(比如, HTTP 500错误)，而有些是隐式(比如，HTTP响应200，但实际业务流程依然是失败的)。

对于一些显式的错误如HTTP 500可以通过在负载均衡器(如Nginx)上进行捕获，而对于一些系统内部的异常，则可能需要直接从服务中添加钩子统计并进行获取。

• 饱和度：衡量当前服务的饱和度。

主要强调最能影响服务状态的受限制的资源。 例如，如果系统主要受内存影响，那就主要关注系统的内存状态，如果系统主要受限与磁盘I/O，那就主要观测磁盘I/O的状态。因为通常情况下，当这些资源达到饱和后，服务的性能会明显下降。同时还可以利用饱和度对系统做出预测，比如，“磁盘是否可能在4个小时候就满了”。

 

 

RED方法

---

RED方法是Weave Cloud在基于Google的“4个黄金指标”的原则下结合Prometheus以及Kubernetes容器实践，细化和总结的方法论，特别适合于云原生应用以及微服务架构应用的监控和度量。主要关注以下三种关键指标：

• (请求)速率：服务每秒接收的请求数。

• (请求)错误：每秒失败的请求数。

• (请求)耗时：每个请求的耗时。

在“4大黄金信号”的原则下，RED方法可以有效的帮助用户衡量云原生以及微服务应用下的用户体验问题。

 

 

USE方法

---

USE方法全称"Utilization Saturation and Errors Method"，主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈以及错误的方法。正如USE方法的名字所表示的含义，USE方法主要关注与资源的：使用率(Utilization)、饱和度(Saturation)以及错误(Errors)。

• 使用率：关注系统资源的使用情况。 这里的资源主要包括但不限于：CPU，内存，网络，磁盘等等。100%的使用率通常是系统性能瓶颈的标志。

• 饱和度：例如CPU的平均运行排队长度，这里主要是针对资源的饱和度(注意，不同于4大黄金信号)。任何资源在某种程度上的饱和都可能导致系统性能的下降。

• 错误：错误计数。例如：“网卡在数据包传输过程中检测到的以太网网络冲突了14次”。

通过对资源以上指标持续观察，通过以下流程可以知道用户识别资源瓶颈：

 

 

 

 

黄金信号，Kubernetes 应用程序监控标准

---

恭喜，您已成功在 Kubernetes 中部署您的应用程序。这时您会发现旧的监控工具几乎毫无用处，并且您无法检测到潜在问题。经典监控工具通常基于静态配置文件，旨在监控机器，而不是微服务或容器。在容器世界中，事情变化很快。容器以令人难以置信的速度创建和销毁，如果没有特定的服务发现功能，就不可能赶上。根据最新的Sysdig 容器使用报告，22% 的容器存活时间不到 10 秒，54% 的容器存活时间不到 5 分钟。

大多数现代监控系统为许多不同的目的提供了种类繁多的指标。很容易淹没在指标中，而忽视与您的应用程序真正相关的内容。设置太多不相关的警报会使您进入永久性紧急状态和“警报耗尽”。想象一下，一个被大量使用并一直在引发负载警报的节点。只要节点中的服务工作，你就不会做任何事情。警报过多与没有警报一样糟糕，因为重要的警报被淹没在无关紧要的海洋中。

这是很多人都面临的问题，幸运的是，已经有人解决了。答案是四个黄金信号，这是Google SRE 手册中首次使用的术语。黄金信号是四个指标，它们可以让您很好地了解与该服务交互的参与者所看到的应用程序的真实健康状况和性能，无论他们是最终用户还是微服务应用程序中的其他服务。

Golden signals metric: Latency explained

---

延迟是您的系统为针对服务的请求提供服务所需的时间。这是检测性能下降问题的重要标志。

使用延迟时，仅使用平均值是不够的，因为它们可能会产生误导。例如，我们有一个服务显示平均 100 毫秒的响应时间。仅凭这些信息我们就可以认为它非常好，但用户的反馈是它被认为是缓慢的。

可以使用不同的统计参数（如标准偏差）来找到这个矛盾的答案，这将使我们了解延迟值的分散情况。如果我们有两种请求，其中一种非常快，另一种较慢，因为它对数据库更加密集。如果一个典型的用户交互有一个慢请求和 10 个快速请求，平均值可能会很低，但应用程序会很慢。瓶颈分析也很重要，不仅仅是平均值。

避免这种行为的一个很好的工具是直方图指标。这些表示不同延迟阈值下的请求数量，并允许它们以百分位数聚合。百分位数是低于给定百分比的度量值的值。例如，p99 表示我 99% 的请求的延迟值低于百分位数。

正如您在屏幕截图中看到的，平均延迟是可以接受的，但是如果我们查看百分位数，我们会发现值存在很大差异，从而更好地了解真实的延迟感知是什么。不同的百分位数表达不同的信息；p50 通常表示一般性能下降，而 p95（或 p99）允许检测特定请求或系统组件中的性能问题。

可能认为 1% 的请求的高延迟不是什么大问题，但现在想想需要多个请求才能完全加载和显示的 Web 应用程序。在这种常见的场景中，1% 的请求中的高延迟会影响最终用户的高得多的速率，因为这些多个请求之一会降低整个应用程序的性能。

另一个用于分析延迟值的有用工具是APDEX 分数，根据您的 SLA 条款，它可以提供基于百分位数的系统状况良好程度的一般概念。

 

Golden signals metric: Errors explained 

---

您的服务返回的错误率是更深层次问题的一个很好的指标。不仅要检测显式错误，还要检测隐式错误，这一点非常重要。

显式错误可以是任何类型的 HTTP 错误代码。这些很容易识别，因为错误代码很容易从回复标头中获得，并且它们在许多系统中都非常一致。这些错误的一些示例可能是授权错误 (503)、未找到内容 (404) 或服务器错误 (500)。在某些情况下，错误描述可能非常具体（418 – 我是茶壶）。

另一方面，隐式错误可能更难检测。带有 HTTP 响应代码 200 但内容中有错误消息的请求怎么样？不同的政策违规也应被视为错误：

• 不生成 HTTP 回复的错误，因为请求时间超过超时时间。
• 明显成功的请求中的内容错误。

When using dashboards to analyze errors, mean values or percentiles do not make any sense. In order to properly see the impact of errors, the best way is to use rates. The percentage of requests that end in errors per second can give detailed information about when the system started to fail and with what impact. 

使用仪表板分析错误时，平均值或百分位数没有任何意义。为了正确地看到错误的影响，最好的方法是使用比率。每秒以错误结束的请求百分比可以提供有关系统何时开始失败以及影响的详细信息。