本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况，请以原始 英文 版本为准，且原始英文版本为权威文本。

监控是如何工作的

1.体系结构概述

*以下部分描述了数据如何在监控 V2 应用程序中流动：*

Prometheus Operator

Prometheus Operator 观察到 ServiceMonitors、PodMonitors 和 Prometheus规则的创建。当 Prometheus 配置资源被创建时，Prometheus Operator 调用 Prometheus API 来同步新的配置。正如本节末尾的图示所示，Prometheus Operator 充当 Prometheus 和 Kubernetes 之间的中介，调用 Prometheus API 将 Prometheus 与 Kubernetes 中的监控相关资源同步。

ServiceMonitors 和 PodMonitors

ServiceMonitors 和 PodMonitors 声明性地指定需要监控的目标，例如 Services 和 Pods。

  • 目标根据配置的 Prometheus 抓取间隔以定期的时间表进行抓取，抓取的指标存储在 Prometheus 时间序列数据库 (TSDB) 中。

  • 为了执行抓取，ServiceMonitors 和 PodMonitors 使用标签选择器来定义哪些 Services 或 Pods 应该被抓取，以及确定如何在给定目标上进行抓取的端点，例如在 TCP 10252 上抓取/metrics，通过 IP 地址 x.x.x.x 进行代理。

  • 开箱即用，监控 V2 附带某些预配置的出口程序，这些出口程序根据其部署的 Kubernetes 集群类型进行部署。有关更多信息，请参见 抓取和暴露指标。

PushProx 的工作原理

  • 某些内部 Kubernetes 组件通过作为监控 V2 一部分部署的代理 PushProx 进行抓取。通过 PushProx 向 Prometheus 暴露指标的 Kubernetes 组件包括：kube-controller-manager、kube-scheduler、etcd 和 kube-proxy。

  • 对于每个 PushProx 出口程序，我们在所有目标节点上部署一个 PushProx 客户端。例如，PushProx 客户端被部署到所有 kube-controller-manager 的控制平面节点、所有 kube-etcd 的 etcd 节点和所有 kubelet 的节点上。

  • 我们为每个出口程序精确部署一个 PushProx 代理。导出指标的过程如下：

    1. PushProx 客户端与 PushProx 代理建立出站连接。

    2. 客户端随后向代理发送轮询请求，以获取进入代理的抓取请求。

    3. 当代理从 Prometheus 接收到抓取请求时，客户端将其视为轮询的结果。

    4. 客户端抓取内部组件。

    5. 内部组件通过将指标推送回代理来响应。

使用PushProx导出指标的流程
Figure 1. 使用PushProx导出指标的流程

PrometheusRules

Prometheus规则允许用户定义哪些指标或时间序列数据库查询应导致警报被触发。规则在一定时间间隔内进行评估。

  • *记录规则*基于已收集的现有时间序列创建新的时间序列。它们通常用于预计算复杂查询。

  • *警报规则*运行特定查询，并在查询评估为非零时触发 Prometheus 的警报。

警报路由

一旦Prometheus确定需要触发警报，警报将被转发到*Alertmanager*。

  • 警报包含来自PromQL查询本身的标签，以及作为指定初始PrometheusRule的一部分可以提供的附加标签和注释。

  • 在接收任何警报之前，Alertmanager将使用其配置中指定的*路由*和*接收器*形成一个路由树，以评估所有传入的警报。路由树的每个节点可以根据附加到Prometheus警报的标签指定需要进行的额外分组、标记和过滤。路由树上的一个节点（通常是叶节点）还可以指定到达它的警报需要发送到配置的接收器，例如Slack、PagerDuty、短信等。请注意，Alertmanager将首先将警报发送到*alertingDriver*，然后alertingDriver将警报发送或转发到正确的目的地。

  • 路由和接收器也通过Alertmanager Secret存储在Kubernetes API中。当Secret更新时，Alertmanager也会自动更新。请注意，路由仅通过标签进行（而不是通过注释等）。

2.Prometheus 的工作原理

存储时间序列数据

在从出口收集指标后，Prometheus 将时间序列存储在本地磁盘时间序列数据库中。Prometheus 可选择与远程系统集成，但 rancher-monitoring 使用本地存储作为时间序列数据库。

一旦存储，用户可以使用 PromQL 查询此 TSDB，这是 Prometheus 的查询语言。

PromQL 查询可以通过两种方式可视化：

  1. 通过在 Prometheus 的图形用户界面中提供查询，这将显示数据的简单图形视图。

  2. 通过创建一个包含 PromQL 查询和额外格式指令的 Grafana 仪表板，这些指令标记轴、添加单位、改变颜色、使用替代可视化等。

为 Prometheus 定义规则

规则定义 Prometheus 需要定期`evaluationInterval`执行的查询，以执行某些操作，例如触发警报（警报规则）或基于 TSDB 中其他现有查询的预计算查询（记录规则）。这些规则被编码在 Prometheus规则自定义资源中。当 PrometheusRule 自定义资源被创建或更新时，Prometheus Operator 观察到变化并调用 Prometheus API 以在定期间隔内同步 Prometheus 当前评估的规则集。

Prometheus规则 允许您定义一个或多个 RuleGroups。每个 RuleGroup 由一组 Rule 对象组成，每个对象可以表示警报规则或记录规则，具有以下字段：

  • 新警报或记录的名称

  • 新警报或记录的 PromQL 表达式

  • 应附加到警报或记录的标签，以识别它（例如，集群名称或严重性）

  • 用于编码任何需要在警报通知中显示的额外重要信息的注释（例如摘要、描述、消息、运行手册 URL 等）。此字段在记录规则中不是必需的。

在评估一个 规则 时，Prometheus 运行提供的 PromQL 查询，添加提供的标签，并执行该规则的适当操作。如果规则触发警报，Prometheus 还会添加提供的注释。例如，一个将 team: front-end 作为标签添加到提供的 PromQL 查询的警报规则，会将该标签附加到触发的警报上，这将允许 Alertmanager 将警报转发到正确的接收者。

警报和记录规则。

Prometheus 不维护警报是否处于活动状态。它在每个评估间隔重复触发警报，依赖 Alertmanager 将警报分组并过滤成有意义的通知。

evaluation_interval 常量定义了 Prometheus 评估其警报规则与时间序列数据库的频率。与 scrape_interval 类似，evaluation_interval 的默认值也为一分钟。

规则包含在一组规则文件中。规则文件包括警报规则和记录规则，但只有警报规则在评估后会触发警报。

对于记录规则，Prometheus 运行一个查询，然后将其存储为时间序列。这个合成时间序列对于存储昂贵或耗时查询的结果非常有用，以便将来可以更快地查询。

警报规则更常用。每当警报规则评估为正数时，Prometheus 会触发警报。

规则文件在触发警报之前根据用例向警报添加标签和注释：

  • 标签指示识别警报的信息，并可能影响警报的路由。例如，在发送关于某个容器的警报时，可以使用容器 ID 作为标签。

  • 注释表示不影响警报路由的信息，例如运行手册或错误消息。

3.Alertmanager 的工作原理。

Alertmanager 处理由客户端应用程序（如 Prometheus 服务器）发送的警报。它负责以下任务：

  • 去重、分组和将警报路由到正确的接收端集成，例如电子邮件、PagerDuty 或 OpsGenie。

  • 静默和抑制警报。

  • 跟踪随时间推移而触发的警报。

  • 发送警报当前是否正在触发或已解决的状态。

由 alertingDrivers 转发的警报。

当安装 alertingDrivers 时，这会创建一个 Service，可以用作 Teams 或 SMS 的接收器 URL，具体取决于 alertingDriver 的配置。接收器中的 URL 指向 alertingDrivers；因此，Alertmanager 首先将警报发送到 alertingDriver，然后 alertingDriver 将警报转发或发送到正确的目的地。

将警报路由到接收器。

Alertmanager 协调警报的发送位置。它允许您根据标签对警报进行分组，并根据是否匹配某些标签来触发它们。一个顶级路由接受所有警报。从那里，Alertmanager 根据警报是否符合下一个路由的条件继续将警报路由到接收器。

虽然 Rancher UI 表单仅允许编辑深度为两级的路由树，但您可以通过编辑 Alertmanager Secret 配置更深层次的嵌套路由结构。

配置多个接收器

通过编辑 Rancher UI 中的表单，您可以设置一个接收器资源，其中包含 Alertmanager 发送警报到您的通知系统所需的所有信息。

通过编辑 Alertmanager 或接收器配置中的自定义 YAML，您还可以将警报发送到多个通知系统。有关更多信息，请参见配置 接收器 的部分。

4.监控 V2 特定组件

Prometheus Operator 引入了一组 自定义资源定义，允许用户通过在集群上创建和修改这些自定义资源来部署和管理 Prometheus 和 Alertmanager 实例。

Prometheus Operator 将根据资源的实时状态和在 Rancher UI 中编辑的配置选项自动更新您的 Prometheus 配置。

默认部署的资源

默认情况下，由 kube-prometheus 项目策划的一组资源会作为安装 Rancher 监控应用程序的一部分部署到您的集群上，以设置基本的监控/警报堆栈。

支持此解决方案的资源可以在 rancher-monitoring Helm 图表中找到，该图表与 Prometheus 社区维护的上游 kube-prometheus-stack Helm 图表密切相关，并在 CHANGELOG.md 中跟踪某些更改。

默认的导出器

监控 V2 部署了三个默认的导出器，提供额外的指标供 Prometheus 存储：

  1. node-exporter: 为 Linux 主机暴露硬件和操作系统指标。有关 node-exporter 的更多信息，请参阅 上游文档。

  2. windows-exporter: 为 Windows 主机暴露硬件和操作系统指标（仅在 Windows 集群上部署）。有关 windows-exporter 的更多信息，请参阅 上游文档。

  3. kube-state-metrics: 暴露跟踪 Kubernetes API 中包含的资源状态的额外指标（例如，pods、工作负载等）。有关 kube-state-metrics 的更多信息，请参阅 上游文档。

ServiceMonitors 和 PodMonitors 将根据 此处 定义抓取这些导出器。Prometheus 存储这些指标，您可以通过 Prometheus 的 UI 或 Grafana 查询结果。

有关记录规则、警报规则和 Alertmanager 的更多信息，请参见 架构 部分。

在 Rancher UI 中暴露的组件

安装监控应用程序后，您将能够在 Rancher UI 中编辑以下组件：

组件 组件类型 编辑的目的和常见用例

ServiceMonitor

自定义资源

设置 Kubernetes 服务以抓取自定义指标。自动更新 Prometheus 自定义资源中的抓取配置。

PodMonitor

自定义资源

设置 Kubernetes Pod 以抓取自定义指标。自动更新 Prometheus 自定义资源中的抓取配置。

接收器

配置块（Alertmanager 的一部分）。

修改发送警报的位置（例如，Slack、PagerDuty等）和发送警报所需的任何信息（例如，TLS证书、代理URL等）。自动更新 Alertmanager 自定义资源。

路由

配置块（Alertmanager 的一部分）。

修改用于根据标签过滤、标记和分组警报的路由树，并将其发送到适当的接收器。自动更新 Alertmanager 自定义资源。

PrometheusRule

自定义资源

定义需要触发警报的额外查询或定义现有系列的物化视图，这些系列在 Prometheus 的 TSDB 中。 自动更新 Prometheus 自定义资源。

PushProx

PushProx 允许 Prometheus 跨网络边界抓取指标，这样用户就不必在 Kubernetes 集群中的每个节点上暴露内部 Kubernetes 组件的指标端口。

由于 Kubernetes 组件的指标通常在集群中节点的主机网络上暴露，PushProx 部署了一个客户端的 DaemonSet，这些客户端位于每个节点的 hostNetwork 上，并与位于 Kubernetes API 上的单个代理建立出站连接。然后可以配置 Prometheus 通过代理向每个客户端发送抓取请求，这样它就可以从内部 Kubernetes 组件抓取指标，而无需打开任何入站节点端口。

有关更多信息，请参阅 使用 PushProx 抓取指标。

5.抓取和暴露指标

定义抓取哪些指标

ServiceMonitors 和 PodMonitors 定义了 Prometheus 要抓取的目标。 Prometheus 自定义资源 告诉 Prometheus 应该使用哪些 ServiceMonitors 或 PodMonitors 来找出从哪里抓取指标。

Prometheus Operator 观察 ServiceMonitors 和 PodMonitors。当它观察到这些被创建或更新时，它调用 Prometheus API 来更新 Prometheus 自定义资源中的抓取配置，并保持与 ServiceMonitors 或 PodMonitors 中的抓取配置同步。该抓取配置告诉 Prometheus 从哪些端点抓取指标，以及它将如何标记来自这些端点的指标。

Prometheus 在每个 scrape_interval 上抓取其抓取配置中定义的所有指标，默认情况下为一分钟。

抓取配置可以作为 Rancher UI 中暴露的 Prometheus 自定义资源的一部分进行查看。

Prometheus Operator如何设置指标抓取

Prometheus 部署或 StatefulSet 抓取指标，Prometheus 的配置由 Prometheus 自定义资源控制。Prometheus Operator 监视 Prometheus 和 Alertmanager 资源，当它们被创建时，Prometheus Operator 会根据用户定义的配置为 Prometheus 或 Alertmanager 创建一个 Deployment 或 StatefulSet。

当 Prometheus Operator 观察到 ServiceMonitors、PodMonitors 和 PrometheusRules 被创建时，它知道需要在 Prometheus 中更新抓取配置。它通过首先更新 Prometheus 的 Deployment 或 StatefulSet 中的配置和规则文件来更新 Prometheus。然后它调用 Prometheus API 来同步新配置，导致 Prometheus 的 Deployment 或 StatefulSet 被就地修改。

Kubernetes 组件指标如何被暴露

Prometheus 从被称为 exporters, 的部署中抓取指标，这些部署以 Prometheus 可以摄取的格式导出时间序列数据。在 Prometheus 中，时间序列由属于同一指标和同一组标记维度的时间戳值流组成。

使用 PushProx 抓取指标

某些内部 Kubernetes 组件通过部署在 Monitoring V2 中、名为 PushProx 的代理进行抓取。有关 PushProx 的详细信息，请参阅 这里 和上述 架构 部分。

抓取指标

以下 Kubernetes 组件由 Prometheus 直接抓取：

  • kubelet*

  • Traefik**

  • coreDns/kubeDns

  • kube-api-server

  • 您可以选择性地使用 hardenedKubelet.enabled 来使用 PushProx，但这不是默认设置。

    • 对于 RKE2 集群，Traefik 默认部署并被视为内部 Kubernetes 组件。

基于 Kubernetes 发行版的指标抓取

根据 Kubernetes 发行版，指标的抓取方式不同。有关术语的帮助，请参见 这里。有关详细信息，请参见下表：

Table 1. 指标如何暴露给 Prometheus
Kubernetes 组件 RKE2 KubeADM K3s

kube-controller-manager

rke2ControllerManager.enabled

kubeAdmControllerManager.enabled

k3sServer.enabled

kube-scheduler

rke2Scheduler.enabled

kubeAdmScheduler.enabled

k3sServer.enabled

etcd

rke2Etcd.enabled

kubeAdmEtcd.enabled

不可用

kube-proxy

rke2Proxy.enabled

kubeAdmProxy.enabled

k3sServer.enabled

kubelet

直接收集 kubelet 暴露的指标

直接收集 kubelet 暴露的指标

直接收集 kubelet 暴露的指标

Traefik*

直接收集 kubelet 暴露的指标

不可用

不可用

coreDns/kubeDns

直接收集 coreDns/kubeDns 暴露的指标

直接收集 coreDns/kubeDns 暴露的指标

直接收集 coreDns/kubeDns 暴露的指标

kube-api-server

直接收集 kube-api-server 暴露的指标

直接收集 kube-appi-server 暴露的指标

直接收集 kube-api-server 暴露的指标

  • 对于 RKE2 集群，Traefik 默认部署并被视为内部 Kubernetes 组件。

术语

  • *kube-scheduler:*内部 Kubernetes 组件，使用 pod 规格中的信息来决定在哪个节点上运行 pod。

  • *kube-controller-manager:*内部 Kubernetes 组件，负责节点管理（检测节点是否失败）、 pod 复制和端点创建。

  • *etcd:*Kubernetes 内部组件，是分布式键值存储，Kubernetes 用于持久存储所有集群信息。

  • *kube-proxy:*Kubernetes 内部组件，监视 API 服务器以获取 pod/service 的变化，以保持网络的最新状态。

  • *kubelet:*Kubernetes 的内部组件，负责监视 API 服务器上节点的 pod，并确保它们正在运行。

  • *Traefik:*Kubernetes 的 Ingress 控制器，可以用作反向代理和负载均衡器。

  • *coreDns/kubeDns:*负责DNS的Kubernetes内部组件。

  • *kube-api-server:*主要的Kubernetes内部组件，负责为其他主组件暴露API。