首先

这个博客的第二部分，从第一部分的文章中我们了解到，监控Kubernetes集群是一个可以通过使用合适的工具来解决的问题。同时，我们还了解到默认的Kubernetes仪表盘可以用来监控集群中运行的各种资源，但这只是基础知识。我们提出了一些工具和平台，如cAdvisor、Kube-state-metrics、Prometheus、Grafana、Kubewatch、Jaeger和MetricFire。

在这篇Part2的博客中，我们将首先查看构建可观察的系统所需的四个黄金信号，然后探讨Prometheus如何有助于应用这些规则。

请先注册MetricFire的免费试用以开始。在此试用期间，您可以通过几乎没有设置来尝试HostedPrometheus。

什么东西坏了，为什么会坏？

DevOps团队的主要工作是让开发团队能够参与运营负责。DevOps是基于不同IT玩家之间的合作，旨在以更快、更便宜、更高质量的方式设计、开发和部署应用程序的实践方法。

为了负责应用程序的运行，DevOps团队不仅需要选择在生产环境中进行监控的适当指标，还需要涉及其他子任务，比如应用程序的监控。被监视的目标和显示的数据会对DevOps方法产生影响。

另外，仅仅让团队参与传统的监视任务是不够的。通过使用监视，可以识别在生产基础设施中发生了什么。可以判断服务器或服务器池中是否存在大量活动。然而，通过使用可观测性（或白盒监控），可以在问题出现之前就检测到问题。

在选择适当的度量标准方面，没有立即可用的方法论。这完全取决于团队的技术和商业需求。然而，参考以下方法也许是一个不错的选择。

• GoogleのGoogleSREブック

ブレンダン・グレッグのUSE Method

トムウィルキーのRED Method

我想要介绍一些基于Google的四个黄金信号的Kubernetes基础生产系统需要监控的常见指标。

分散系统监控：四个黄金信号

在著名的谷歌SRE图书第六章中，谷歌定义了四个主要的监控信号，以确保持续监视。这四个信号被称为延迟、流量、错误和饱和度的四个黄金信号。

这些信号非常重要，因为它们对确保应用程序的高可用性至关重要。我将简要解释每个信号的意思。

延迟

延迟是指发送请求并接收响应所需的时间。通常在服务器端进行测量，但也可以考虑客户端的测量，以考虑网络速度差异。运营团队可以最好地控制服务器端的延迟，但对于终端客户来说，客户端端的延迟更为合适。

选择目标阈值可能因应用程序类型而异。此外，由于失败请求往往很快失败，无需进一步处理，因此需要明确跟踪成功和失败请求的延迟。

交通

网络流量是衡量通过网络传输的数据量的标准。这些数据可以是发送到Web服务器或API服务器的HTTP请求，也可以是发送到处理队列的消息。流量的高峰期间可能会给基础设施带来压力，将基础设施推向极限，并可能对下游产生影响。因此，流量是一个重要的信号。它有助于区分导致相同结果的两个不同根本原因。系统配置问题可能在流量较少的情况下也会导致问题，这涉及容量问题和不适当的系统配置。

对于分布式系统，尤其是Kubernetes的情况，这将有助于事先规划容量以满足未来的需求。

错误

错误会告诉我们代码中的错误、未解决的依赖关系或基础设施配置错误。我们拿数据库故障导致错误率飙升的例子来比较，通常与网络错误引起的同样的错误率飙升结果相比较。仅仅通过错误率无法了解问题所在。

在Kubernetes部署更改后，错误可能显示了代码中的一个漏洞，这个漏洞没有在测试中被发现，或者只在生产系统中显示出来。

因此，错误消息可以提供有关问题更准确的报告。错误可能会对其他指标产生影响，例如人为减少延迟，错误可能会导致重复尝试，并可能导致 Kubernetes 集群崩溃。

饱和状态 hé

サチュレーション是指对网络、CPU等服务器资源的负载。每个资源都有限制，超出限制后会导致性能下降或完全无法使用。

饱和状态适用于磁盘容量（每秒读/写操作）、CPU使用率、内存使用量和其他资源等资源。在Kubernetes集群的设计中，需要意识到必须应对服务的哪一部分最有可能首先处于饱和状态。

通常情况下，我们使用的度量指标是先行指标，因此可以在性能下降之前进行容量调整。例如，当网络饱和时，可能会丢失数据包。此外，当CPU使用率达到最大时，可能会出现响应延迟；当磁盘使用率达到最大时，可能会发生写入错误或数据丢失。

普罗米修斯和四个黄金信号。

Prometheus是一个开源工具，用于监控和警告。它最初由SoundCloud开发，然后捐赠给CNCF。该工具使用度量出口器与其他应用程序进行本地或间接集成。使用Prometheus Operator，在Kubernetes上安装和管理Prometheus比预期更加简便。Prometheus Operator是在Kubernetes集群中运行PrometheusAlertmanager和Grafana的简单方法。那么，为了实现四个黄金信号，Prometheus需要监视哪些度量指标呢？

虽然Prometheus收集和保存了很多指标，但我们只选择其中的一些作为演示。因此，下面的列表并没有涵盖所有指标。

首先，”http_requests_total” 是用来计算发出的HTTP响应数量，并按照代码和方法进行分类的。它可用于监控流量。

我去买菜的时候，忘记带钥匙了，所以无法进入家门。

sum(rate(http_requests_total[1m]))

您可以使用诸如「node_network_transmit_bytes」和「node_network_receive_bytes」等其他指标来监控流量。适当的指标选择取决于需要测量的内容和使用情况。您可能想监控HTTP请求、TCP请求、传输和接收的字节数，这取决于个人情况。

在中国官方语言中，以下是对原文的一个选项进行释义：

另一个重要的性能指标是延迟，也可以通过使用” http_request_duration_seconds “等度量来观察。通过使用PromQL，我们可以获得在400毫秒内完成的请求的比例。

sum(rate(http_request_duration_seconds_bucket{le="0.4"}[1m])) / sum(rate(http_request_duration_seconds_count[1m]))

通过使用诸如”http_status_500_total”和”http_responses_total”等指标，您可以以几乎相同的方式来测量错误率。

rate(http_status_500_total [1m]) / rate(http_requests_total [1m])

或者,

sum(rate(http_responses_total{code="500"}[1m])) / sum(rate(http_responses_total[1m]))

通常情况下，要测量系统的各种情况，如内存、硬盘、CPU等，必须参考系统指标。这些类型的指标可以直接从Kubernetes节点收集，而不依赖于仪器仪表。例如，要监控CPU的饱和状态，需要使用来自节点导出器的”cpu”指标，并将其与时间平均函数结合使用。

avg_over_time(cpu[1m])

如果需要将相同的东西应用到光盘或其他资源上，可以使用以下选项：
– 如果需要将相同的东西应用到光盘或其他资源上，可以尝试以下方法。

avg_over_time (node_disk_io_time_seconds_total[1m])

总结

如果您理解了Kubernetes集群的设计以及它所运行的服务的特性，您可以轻松选择适当的指标，并且这四个黄金信号将有助于设计可观察的系统。但是，要充分利用Prometheus的功能，您需要从使用基本指标开始，然后扩展到其他高级功能，如AlertManager，并将数据和警报集成到Grafana仪表板中。有关AlertManager的详细使用方法，请参阅与AlertManager的前五个陷阱相关的文章。另外，您可以注册MetricFire的免费试用版或预订演示来了解有关Prometheus度量监控的详细信息，或者联系我们咨询。