1.3. 了解监控堆栈 - 主要概念 | 监控 | Red Hat OpenShift Service on AWS | 4

1.3.1. 关于性能和可扩展性

您可以优化集群的性能和扩展。您可以通过执行以下操作配置监控堆栈：

控制监控组件的放置和分发：
- 使用节点选择器将组件移到特定的节点。
- 分配容限以启用将组件移到污点节点。
使用 pod 拓扑分布限制。
管理 CPU 和内存资源。

1.3.1.1. 使用节点选择器移动监控组件

通过将 nodeSelector 约束与标记的节点搭配使用，您可以将任何监控堆栈组件移到特定的节点上。通过这样做，您可以控制集群中监控组件的放置和分发。

通过控制监控组件的放置和分发，您可以根据特定要求或策略优化系统资源使用、提高性能和单独的工作负载。

节点选择器与其他约束一起使用

如果使用节点选择器约束移动监控组件，请注意集群可能存在其他限制来控制 pod 调度：

拓扑分布约束可能处于放置状态来控制 pod 放置。
Prometheus、Alertmanager 和其他监控组件会放置硬反关联性规则，以确保这些组件的多个 pod 始终分散到不同的节点上，因此始终具有高可用性。

将 pod 调度到节点时，pod 调度程序会在决定 pod 放置时尝试满足所有现有的限制。也就是说，当 pod 调度程序决定将哪些 pod 放置到哪些节点上时，所有约束都会编译。

因此，如果您配置节点选择器约束，但无法满足现有的约束，pod 调度程序无法与所有约束匹配，也不会调度 pod 放置到节点上。

为保持监控组件的弹性和高可用性，请确保有足够的节点可用，并在配置节点选择器约束以移动组件时匹配所有约束。

1.3.1.2. 关于用于监控的 pod 拓扑分布限制

当 Red Hat OpenShift Service on AWS pod 部署到多个可用区时，您可以使用 pod 拓扑分布约束来控制监控 pod 如何分散到网络拓扑中。

Pod 拓扑分布约束适合在分层拓扑内控制 pod 调度，节点分散到不同的基础架构级别，如这些区域内的地区和区域。另外，通过能够在不同区中调度 pod，您可以在某些情况下提高网络延迟。

您可以为 Cluster Monitoring Operator 部署的所有 pod 配置 pod 拓扑分布限制，以控制如何在区调度到节点的 pod 副本。这样可确保 pod 具有高可用性并更有效地运行，因为工作负载分散在不同的数据中心或分层基础架构区域中。

1.3.1.3. 关于为监控组件指定限制和请求

您可以为监控用户定义的项目的以下组件配置资源限值和请求：

Alertmanager
Prometheus
Thanos Ruler

通过定义资源限值，您可以限制容器的资源使用情况，这会阻止容器超过 CPU 和内存资源指定的最大值。

通过定义资源请求，您可以指定容器只能调度到具有足够 CPU 和内存资源的节点，以匹配请求的资源。

1.3.2. 关于存储和记录数据

您可以存储和记录数据，以帮助您保护数据并使用它们进行故障排除。您可以通过执行以下操作配置监控堆栈：

配置持久性存储：
- 通过将指标和警报数据存储在持久性卷(PV)中来保护您的指标和警报数据。因此，它们可以在 pod 重启或重新创建后保留。
- 避免获取重复的通知，并在 Alertmanager pod 重启时丢失警报静默。
修改 Prometheus 和 Thanos Ruler 指标数据的保留时间和大小。
配置日志记录以帮助您排除集群的问题：
- 为监控设置日志级别。
- 为 Prometheus 和 Thanos Querier 启用查询日志记录。

1.3.2.1. Prometheus 指标的保留时间和大小

默认情况下，Prometheus 会在以下持续时间内保留指标数据：

核心平台监控 ：15 天
监控用户定义的项目: 24 小时

您可以修改 Prometheus 实例的保留时间，以更改在多久后删除数据。您还可以设置保留指标数据使用的最大磁盘空间量。如果数据达到这个大小限制，Prometheus 会首先删除最旧的数据，直到使用的磁盘空间重新低于限制。

请注意这些数据保留设置的行为：

基于大小的保留策略适用于 /prometheus 目录中的所有数据块目录，包括持久性块、写入级日志(WAL)数据和 mmapped 块。
/wal 和 /head_chunks 目录中的数据计入保留大小限制，但 Prometheus 永远不会根据基于大小或基于时间的保留策略从这些目录中清除数据。因此，如果您设置了保留大小限制，它小于为 /wal 和 /head_chunks 目录设置的最大容量，则表示您将系统配置为不保留 /prometheus 数据目录中的任何数据块。
只有在 Prometheus 切断新的数据块时，才会应用基于大小的保留策略，即在 WAL 最多包含三小时数据后每两小时进行。
如果没有为 retention 或 retentionSize 明确定义值，则保留时间默认为 15 天，用于核心平台监控，为用户定义的项目监控 24 小时。不设置保留大小。
如果 retention 和 retentionSize 都定义了值，则会应用这两个值。如果任何数据块超过定义的保留时间或定义的大小限制，Prometheus 会清除这些数据块。
如果您为 retentionSize 定义了值，且没有定义 retention，则只应用 retentionSize 值。
如果您没有为 retentionSize 定义值，且只为 retention 定义了值，则只应用 retention 值。
如果将 retentionSize 或 retention 值设置为 0，则应用默认的设置。默认设置将核心平台监控的保留时间设置为 15 天，用户定义的项目监控为 24 小时。默认情况下，不会设置保留大小。

注意

数据压缩每两小时进行。因此，持久性卷(PV)可能会在压缩前填满，可能会超过 retentionSize 限制。在这种情况下，KubePersistentVolumeFillingUp 警报会触发，直到 PV 上的空间低于 retentionSize 限制。

1.3.3. 了解指标

在 Red Hat OpenShift Service on AWS 中，集群组件的监控方式是提取通过服务端点公开的指标。您还可以为用户定义的项目配置指标集合。借助指标，您可以监控集群组件和您自己的工作负载的表现情况。

您可以通过在应用程序级别使用 Prometheus 客户端库来定义您要为您自己的工作负载提供的指标。

在 Red Hat OpenShift Service on AWS 中，指标通过 /metrics 规范名称下的 HTTP 服务端点公开。您可以通过针对 http://<endpoint>/metrics 运行 curl 查询来列出服务的所有可用指标。例如，您可以向 prometheus-example-app 示例应用程序公开路由，然后运行以下命令来查看其所有可用指标：

curl http://<example_app_endpoint>/metrics

$ curl http://<example_app_endpoint>/metrics

Copy to Clipboard

输出示例

HELP http_requests_total Count of all HTTP requests
TYPE http_requests_total counter
HELP version Version information about this binary
TYPE version gauge

# HELP http_requests_total Count of all HTTP requests
# TYPE http_requests_total counter
http_requests_total{code="200",method="get"} 4
http_requests_total{code="404",method="get"} 2
# HELP version Version information about this binary
# TYPE version gauge
version{version="v0.1.0"} 1

Copy to Clipboard

1.3.3.1. 控制用户定义的项目中未绑定指标属性的影响

开发人员可以使用键值对的形式为指标定义属性。潜在的键值对数量与属性的可能值数量对应。具有无限数量可能值的属性被称为未绑定属性。例如，customer_id 属性不绑定，因为它有无限多个可能的值。

每个分配的键值对都有唯一的时间序列。在标签中使用许多未绑定属性可导致所创建的时间序列数量出现指数增加。这可能会影响 Prometheus 性能，并消耗大量磁盘空间。

dedicated-admin 可以使用以下方法控制用户定义的项目中未绑定指标属性的影响：

限制用户定义的项目中每个目标提取可接受的示例数量
限制提取的标签数量、标签名称长度以及标签值长度
配置连续提取和 Prometheus 规则评估之间的间隔
创建在达到提取示例阈值或无法提取目标时触发的警报

注意

限制提取示例可帮助防止在标签中添加多个未绑定属性导致的问题。开发人员还可以通过限制其为指标定义的未绑定属性数量来防止底层原因。使用绑定到一组有限可能值的属性可减少潜在的键-值对组合数量。

1.3.3.2. 在指标中添加集群 ID 标签

如果您管理多个 Red Hat OpenShift Service on AWS 集群，并使用远程写入功能将指标数据从这些集群发送到外部存储位置，您可以添加集群 ID 标签来识别来自不同集群的指标数据。然后，您可以查询这些标签来标识指标的源集群，并区分与其他集群发送的类似指标数据的数据。

这样，如果您为多个客户管理多个集群，并将指标数据发送到单个集中存储系统，您可以使用集群 ID 标签查询特定集群或客户的指标。

创建并使用集群 ID 标签涉及三个常规步骤：

配置远程写入存储的写重新标记设置。
将集群 ID 标签添加到指标。
查询这些标签以标识源集群或指标客户。

1.3.4. 关于监控仪表板

Red Hat OpenShift Service on AWS 提供了一组监控仪表板，可帮助您了解集群组件和用户定义的工作负载的状态。

重要

从 Red Hat OpenShift Service on AWS 4.19 开始，Web 控制台中的视角会统一。Developer 视角不再默认启用。

所有用户都可以与所有 {rosa-classic-short} web 控制台功能交互。但是，如果您不是集群所有者，您可能需要从集群所有者请求权限。

您仍然可以启用 Developer 视角。在 web 控制台中的 Getting Started 窗格中，您可以浏览控制台，查找有关设置集群的信息，查看启用 Developer 视角的快速启动，并按照链接探索新功能。

作为管理员，您可以访问 Red Hat OpenShift Service on AWS 核心组件的仪表板，包括以下项目：

API 性能
etcd
Kubernetes 计算资源
Kubernetes 网络资源
Prometheus
与集群和节点性能相关的 USE 方法仪表板
节点性能指标

1.3.5. 管理警报

在 Red Hat OpenShift Service on AWS 中，您可以通过 Alerting UI 管理警报、静默和警报规则。

警报规则。警报规则包含一组概述集群中特定状态的条件。当这些条件满足时会触发警报。可为警报规则分配一个严重性来定义警报的路由方式。
警报。当警报规则中定义的条件为满足时会触发警报。警报提供一条通知，说明 Red Hat OpenShift Service on AWS 集群中的一组情况是明显的。
静默。可对警报应用静默，以防止在警报条件满足时发送通知。您可以在初始通知后静默警报，同时工作来解决此问题。

注意

Alerting UI 中可用的警报、静默和警报规则与您可访问的项目相关。例如，如果您以具有 cluster-admin 角色的用户身份登录，您可以访问所有警报、静默和警报规则。

1.3.5.1. 管理静默

您可以在 Red Hat OpenShift Service on AWS Web 控制台中为警报创建静默。创建静默后，不会在警报触发时收到有关警报的通知。

当您收到了初始警报通知，并且不希望在解决与这个初始警报相关的底层问题时接收到因为解决相关问题所触发的警报通知，可以创建静默。

在创建静默时，您必须指定它是立即激活，还是稍后激活。您还必须设置静默在多长一段时间后到期。

在创建静默后，您可以查看、编辑这个静默，并可以使其过期。

注意

在创建静默时，它们会在 Alertmanager pod 之间复制。但是，如果您没有为 Alertmanager 配置持久性存储，静默可能会丢失。例如，如果所有 Alertmanager pod 同时重启，会出现这种情况。

1.3.5.2. 为用户定义的项目创建警报规则

在 Red Hat OpenShift Service on AWS 中，您可以为用户定义的项目创建警报规则。这些警报规则将根据所选指标的值触发警报。

如果您为用户定义的项目创建警报规则，请在定义新规则时请考虑以下关键行为和重要限制：

除了核心平台监控的默认指标外，用户定义的警报规则也可以包括由其自身项目公开的指标。您不能包含其他用户定义的项目的指标。
例如，ns1 用户定义的项目的警报规则除核心平台指标（如 CPU 和内存指标）外还可以使用 ns1 项目公开的指标。但是，该规则无法包含来自不同 ns2 用户定义的项目的指标。
默认情况下，当您创建警报规则时，即使另一个项目中存在具有相同名称的规则，也会在其上强制实施 namespace 标签。要创建不绑定到源项目的警报规则，请参阅"为用户定义的项目创建跨项目警报规则"。
要缩短延迟并最小化核心平台监控组件的负载，您可以将 openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus 标签添加到规则中。此标签只强制 openshift-user-workload-monitoring 项目中部署的 Prometheus 实例评估警报规则，并防止 Thanos Ruler 实例这样做。
重要
如果警报规则具有此标签，则您的警报规则只能使用用户定义的项目公开的这些指标。您基于默认平台指标创建的警报规则可能无法触发警报。

1.3.5.3. 为用户定义的项目管理警报规则

在 Red Hat OpenShift Service on AWS 中，您可以在用户定义的项目中查看、编辑和删除警报规则。

重要

为用户定义的项目管理警报规则仅在 Red Hat OpenShift Service on AWS 版本 4.11 及更新的版本中可用。

警报规则注意事项

默认警报规则专门用于 Red Hat OpenShift Service on AWS 集群。
有些警报规则特意使用相同的名称。它们发送关于同一事件但具有不同阈值和/或不同严重性的警报。
如果较低严重性警报在较高严重性警报触发的同时触发，禁止规则可防止在这种情况下发送通知。

1.3.5.4. 为用户定义的项目优化警报

要优化您自己的项目的警报，您可以在创建警报规则时考虑以下建议：

尽可能减少您为项目创建的警报规则数量。创建警报规则来针对会影响您的条件通知您。如果您为不会影响您的条件生成多个警报，则更难以注意到相关警报。
为症状而不是原因创建警报规则。创建警报规则来针对条件通知您，而无论根本原因是什么。然后可以调查原因。如果每个警报规则都只与特定原因相关，则需要更多警报规则。然后，可能会错过一些原因。
在编写警报规则前进行规划。确定对您很重要的症状以及一旦发生您想要采取什么操作。然后为每个症状构建警报规则。
提供明确的警报信息。在警报消息中说明症状和推荐操作。
在警报规则中包含严重性级别。警报的严重性取决于当报告的症状发生时您需要如何做出反应。例如，如果症状需要个人或关键响应团队立即关注，就应该触发关键警报。

1.3.5.5. 搜索和过滤警报、静默和警报规则

您可以过滤 Alerting UI 中显示的警报、静默和警报规则。本节介绍每个可用的过滤选项。

1.3.5.5.1. 了解警报过滤器

Alerting UI 中的 Alerts 页面提供有关与 AWS 默认 Red Hat OpenShift Service on AWS 和用户定义的项目相关的警报的详细信息。该页面包括每个警报的严重性、状态和来源摘要。另外还会显示警报进入其当前状态的时间。

您可以按警报状态、严重性和来源进行过滤。默认情况下，只会显示处于 Firing 状态的 Platform 警报。下面描述了每个警报过滤选项：

State 过滤器：
- Firing。警报正在触发，因为满足警报条件，且可选的 for 持续时间已过。当条件保持 true 时，警报将继续触发。
- Pending。该警报处于活跃状态，但正在等待警报规则中指定的持续时间，然后再触发警报。
- Silenced。现在，警报在定义的时间段内处于静默状态。静默会根据您定义的一组标签选择器临时将警报静音。对于与所有列出的值或正则表达式匹配的警报，不会发送通知。
Severity 过滤器：
- Critical。触发了警报的条件可能会产生重大影响。该警报在触发时需要立即关注，并且通常会传给个人或关键响应团队。
- Warning。该警报针对可能需要注意的事件提供警告通知，以防止问题的发生。警告通常会路由到一个问题单系统进行非即时的审阅。
- Info。该警报仅用于提供信息。
- None。该警报没有定义的严重性。
- 您还可以针对与用户定义的项目相关的警报创建自定义严重性定义。
Source 过滤器：
- Platform。平台级别的警报仅与默认的 Red Hat OpenShift Service on AWS 项目相关。这些项目提供 Red Hat OpenShift Service on AWS 核心功能。
- User。用户警报与用户定义的项目相关。这些警报是用户创建的，并可自定义。用户定义的工作负载监控可在安装后启用，以便您观察自己的工作负载。

1.3.5.5.2. 了解静默过滤器

Alerting UI 中的 Silences 页面提供有关在默认 Red Hat OpenShift Service on AWS 和用户定义的项目中应用到警报的静默的详细信息。该页面包括每个静默的状态以及静默结束时间的摘要。

您可以按静默状态进行过滤。默认情况下，仅显示 Active 和 Pending 静默。下面描述了每个静默状态过滤器选项：

State 过滤器：
- Active。静默处于活跃状态，在静默到期前，警报将静音。
- Pending。静默已被调度，但还没有激活。
- Expired。静默已过期，如果满足警报条件，将发送通知。

1.3.5.5.3. 了解警报规则过滤器

Alerting UI 中的 Alerting rules 页面提供有关与默认 Red Hat OpenShift Service on AWS 和用户定义的项目相关的警报规则的详细信息。该页面包括每个警报规则的状态、严重性和来源摘要。

您可以按警报状态、严重性和来源过滤警报规则。默认情况下，只会显示 Platform 警报规则。下面描述了每个警报规则过滤选项：

警报状态 过滤器：
- Firing。警报正在触发，因为满足警报条件，且可选的 for 持续时间已过。当条件保持 true 时，警报将继续触发。
- Pending。该警报处于活跃状态，但正在等待警报规则中指定的持续时间，然后再触发警报。
- Silenced。现在，警报在定义的时间段内处于静默状态。静默会根据您定义的一组标签选择器临时将警报静音。对于与所有列出的值或正则表达式匹配的警报，不会发送通知。
- Not Firing。警报未触发。
Severity 过滤器：
- Critical。警报规则中定义的条件可能会产生重大影响。如果满足这些条件，需要立即关注。与该规则相关的警报通常会传给个人或关键响应团队。
- Warning。警报规则中定义的条件可能需要注意，以防止问题的发生。与该规则相关的警报通常会路由到一个问题单系统进行非即时的审阅。
- Info。警报规则仅提供信息警报。
- None。该警报规则没有定义的严重性。
- 您还可以针对与用户定义的项目相关的警报规则创建自定义严重性定义。
Source 过滤器：
- Platform。平台级别的警报规则仅与 Red Hat OpenShift Service on AWS 项目相关。这些项目提供 Red Hat OpenShift Service on AWS 核心功能。
- User。用户定义的工作负载警报规则与用户定义的项目相关。这些警报规则是用户创建的，并可自定义。用户定义的工作负载监控可在安装后启用，以便您观察自己的工作负载。

1.3.6. 了解用户定义的项目的警报路由

作为 dedicated-admin，您可以为用户定义的项目启用警报路由。使用此功能，您可以允许具有 alert-routing-edit 集群角色的用户为用户定义的项目配置警报通知路由和接收器。这些通知由专用于用户定义的监控的 Alertmanager 实例路由。

然后，用户可以通过为用户定义的项目创建或编辑 AlertmanagerConfig 对象来创建和配置用户定义的警报路由，而无需管理员的帮助。

用户为用户定义的项目定义了警报路由后，用户定义的警报通知将路由到 openshift-user-workload-monitoring 命名空间中的 alertmanager-user-workload Pod。

注意

查看用户定义的项目的警报路由的以下限制：

对于用户定义的警报规则，用户定义的路由范围到定义资源的命名空间。例如，命名空间 ns1 中的路由配置仅适用于同一命名空间中的 PrometheusRules 资源。
当命名空间不包括在用户定义的监控中时，命名空间中的 AlertmanagerConfig 资源将成为 Alertmanager 配置的一部分。

1.3.7. 将通知发送到外部系统

在 Red Hat OpenShift Service on AWS 4 中，可在 Alerting UI 中查看触发警报。默认不会将警报配置为发送到任何通知系统。您可以配置 Red Hat OpenShift Service on AWS，将警报发送到以下接收器类型：

PagerDuty
Webhook
电子邮件
Slack
Microsoft Teams

通过将警报路由到接收器，您可在出现故障时及时向适当的团队发送通知。例如，关键警报需要立即关注，通常会传给个人或关键响应团队。相反，提供非关键警告通知的警报可能会被路由到一个问题单系统进行非即时的审阅。

使用 watchdog 警报检查警报是否工作正常

Red Hat OpenShift Service on AWS 监控包括持续触发的 watchdog 警报。Alertmanager 重复向已配置的通知提供程序发送 watchdog 警报通知。此提供程序通常会配置为在其停止收到 watchdog 警报时通知管理员。这种机制可帮助您快速识别 Alertmanager 和通知提供程序之间的任何通信问题。

1.3. 了解监控堆栈 - 主要概念