Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

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

熟悉 OpenShift Container Platform 监控概念和术语。了解如何提高集群的性能和规模，存储和记录数据，管理指标和警报等。

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 拓扑分布限制

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

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

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

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

您可以为以下核心平台监控组件配置资源限值和请求：

  • Alertmanager
  • kube-state-metrics
  • monitoring-plugin
  • node-exporter
  • openshift-state-metrics
  • Prometheus
  • 指标服务器
  • Prometheus Operator 及其准入 Webhook 服务
  • Telemeter Client
  • Thanos querier

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

  • Alertmanager
  • Prometheus
  • Thanos Ruler

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

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

1.3.1.4. 关于指标集合配置集

重要

指标集合配置集只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

默认情况下，Prometheus 会收集由 OpenShift Container Platform 组件中的所有默认指标目标公开的指标。但是，在某些情况下，您可能希望 Prometheus 从集群收集较少的指标：

  • 集群管理员只需要警报、遥测和控制台指标，且不需要其他指标数据。
  • 集群大小增加，且收集的默认指标数据的大小现在需要显著增加 CPU 和内存资源。

您可以使用指标集合配置集来收集默认指标数据数量或最小指标数据。当您收集最小指标数据时，警报等基本监控功能将继续工作。同时，Prometheus 所需的 CPU 和内存资源会减少。

您可以启用两个指标集合配置集之一：

  • full ：Prometheus 会收集由所有平台组件公开的指标数据。此设置是默认设置。
  • minimal ：Prometheus 仅收集平台警报、记录规则、遥测和控制台仪表板所需的指标数据。

1.3.2. 关于存储和记录数据

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

  • 配置持久性存储：

    • 通过将指标和警报数据存储在持久性卷(PV)中来保护您的指标和警报数据。因此，它们可以在 pod 重启或重新创建后保留。
    • 避免获取重复的通知，并在 Alertmanager pod 重启时丢失警报静默。
  • 修改 Prometheus 和 Thanos Ruler 指标数据的保留时间和大小。

  • 配置日志记录以帮助您排除集群的问题：

    • 为 Metrics 服务器配置审计日志。
    • 为监控设置日志级别。
    • 为 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. 了解指标

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

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

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

$ curl http://<example_app_endpoint>/metrics

输出示例

# 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

其他资源

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

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

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

集群管理员可以使用以下方法控制用户定义的项目中未绑定指标属性的影响：

  • 限制用户定义的项目中每个目标提取可接受的示例数量
  • 限制提取标签数量、标签名称长度以及标签值长度
  • 创建在达到提取示例阈值或无法提取目标时触发的警报
注意

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

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

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

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

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

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

1.3.4. 关于监控仪表板

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

其他资源

1.3.4.1. Administrator 视角中的监控仪表板

使用 Administrator 视角访问 OpenShift Container Platform 核心组件的仪表板，包括以下项目：

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

图 1.1. Administrator 视角中的仪表板示例

监控仪表板管理员

1.3.4.2. Developer 视角中的监控仪表板

使用 Developer 视角访问为所选项目提供以下应用程序指标的 Kubernetes 计算资源仪表板：

  • CPU 用量
  • 内存用量
  • 带宽信息
  • 数据包速率信息

图 1.2. Developer 视角中的仪表板示例

观察仪表板开发人员

1.3.5. 管理警报

在 OpenShift Container Platform 中，您可以通过 Alerting UI 管理警报、静默和警报规则。

  • 警报规则。警报规则包含一组概述集群中特定状态的条件。当这些条件满足时会触发警报。可为警报规则分配一个严重性来定义警报的路由方式。
  • 警报。当警报规则中定义的条件为满足时会触发警报。警报提供一条通知，说明一组情况在 OpenShift Container Platform 集群中显而易见。
  • 静默。可对警报应用静默，以防止在警报条件满足时发送通知。在您着手处理根本问题的同时，可在初始通知后将警报静音。
注意

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

其他资源

1.3.5.1. 管理静默

您可以在 Administrator 和 Developer 视角中的 OpenShift Container Platform Web 控制台中为警报创建静默。创建静默后，不会在警报触发时收到有关警报的通知。

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

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

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

注意

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

1.3.5.2. 管理用于核心平台监控的警报规则

OpenShift Container Platform 监控包括一组用于平台指标的默认警报规则。作为集群管理员，您可以以两种方式自定义这组规则：

  • 通过调整阈值或添加和修改标签来修改现有平台警报规则的设置。例如，您可以将一个警报的 severity 标签从 warning 改为 critical 以帮助您来处理相关的问题。
  • 通过基于 openshift-monitoring 命名空间中的核心平台指标构建查询表达式，定义和添加新的自定义警报规则。

核心平台警报规则考虑

  • 新的警报规则必须基于默认的 OpenShift Container Platform 监控指标。
  • 您必须在 openshift-monitoring 命名空间中创建 AlertingRule 和 AlertRelabelConfig 对象。
  • 您只能添加和修改警报规则。您无法创建新的记录规则或修改现有的记录规则。
  • 如果您使用 AlertRelabelConfig 对象修改现有平台警报规则，您的修改不会反映在 Prometheus 警报 API 中。因此，任何丢弃的警报仍出现在 OpenShift Container Platform web 控制台中，即使它们不再被转发到 Alertmanager。另外，任何对警报的修改（如更改了 severity 标签）都不会出现在 web 控制台中。

1.3.5.3. 为核心平台监控优化警报规则的建议

如果您需要自定义核心平台警报规则来满足机构的特定需求，请遵循以下准则，确保自定义规则可以实现预期的目且高效。

  • 使用尽可能少的新规则。仅创建符合您特定要求的规则。通过使用最少的规则数量，您可以在监控环境中创建更易管理且集中的警报系统。
  • 专注于症状而不是原因。创建规则来通知用户症状而不是造成症状的根本原因。这可以确保，在出现相关症状时用户可以获得警报，用户可以调查触发警报的根本原因。使用这个策略，可以显著降低了您需要创建的规则的总数量。
  • 在实施更改之前，规划并评估您的需求。首先，明确哪些症状是重要的，以及在出现这些症状时您希望用户执行哪些操作。然后，评估现有规则，决定是否可以通过修改这些规则来实现您的目的，而不用为每个症状都创建一个新的规则。通过修改现有规则并谨慎创建新规则，可帮助您简化警报系统。
  • 提供明确的警报信息。当您创建警报消息时，包括症状的描述、可能的原因和推荐的操作。包括的信息应该明确、简明，并包括故障排除步骤或更多相关信息的链接。这样做有助于用户快速评估情况并做出适当响应。
  • 包括严重性级别。为您的规则分配严重性级别，以提示用户在出现症状并触发警报时如何响应。例如，将警报严重性级别定为 关键（Critical） 信号，代表相关人员需要马上做出响应。通过定义严重性级别，可以帮助用户决定在收到警报时应如何响应，并确保对紧急的问题马上做出响应

1.3.5.4. 关于为用户定义的项目创建警报规则

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

  • 除了核心平台监控的默认指标外，用户定义的警报规则也可以包括由其自身项目公开的指标。您不能包含其他用户定义的项目的指标。

    例如，ns1 用户定义的项目的警报规则除核心平台指标（如 CPU 和内存指标）外还可以使用 ns1 项目公开的指标。但是，该规则无法包含来自不同 ns2 用户定义的项目的指标。

  • 要缩短延迟并最小化核心平台监控组件的负载，您可以将 openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus 标签添加到规则中。此标签只强制 openshift-user-workload-monitoring 项目中部署的 Prometheus 实例评估警报规则，并防止 Thanos Ruler 实例这样做。

    重要

    如果警报规则具有此标签，则您的警报规则只能使用用户定义的项目公开的这些指标。您基于默认平台指标创建的警报规则可能无法触发警报。

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

在 OpenShift Container Platform 中，您可以查看、编辑和删除用户定义的项目中的警报规则。

警报规则注意事项

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

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

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

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

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

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

1.3.5.7.1. 了解警报过滤器

在 Administrator 视角中，Alerting UI 中的 Alerts 页面针对与 OpenShift Container Platform 默认项目和用户定义的项目相关的警报提供了详细信息。该页面包括每个警报的严重性、状态和来源摘要。另外还会显示警报进入其当前状态的时间。

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

  • State 过滤器：

    • Firing。警报正在触发，因为满足警报条件，且可选的 for 持续时间已过。当条件保持 true 时，警报将继续触发。
    • Pending。该警报处于活跃状态，但正在等待警报规则中指定的持续时间，然后再触发警报。
    • Silenced。现在，警报在定义的时间段内处于静默状态。静默会根据您定义的一组标签选择器临时将警报静音。对于与所有列出的值或正则表达式匹配的警报，不会发送通知。

  • Severity 过滤器：

    • Critical。触发了警报的条件可能会产生重大影响。该警报在触发时需要立即关注，并且通常会传给个人或关键响应团队。
    • Warning。该警报针对可能需要注意的事件提供警告通知，以防止问题的发生。警告通常会路由到一个问题单系统进行非即时的审阅。
    • Info。该警报仅用于提供信息。
    • None。该警报没有定义的严重性。
    • 您还可以针对与用户定义的项目相关的警报创建自定义严重性定义。

  • Source 过滤器：

    • Platform。平台级别的警报仅与 OpenShift Container Platform 默认项目相关。这些项目提供 OpenShift Container Platform 核心功能。
    • User。用户警报与用户定义的项目相关。这些警报是用户创建的，并可自定义。用户定义的工作负载监控可在安装后启用，以便您观察自己的工作负载。
1.3.5.7.2. 了解静默过滤器

在 Administrator 视角中，Alerting UI 中的 Silences 页面针对应用到 OpenShift Container Platform 默认项目和用户定义项目中的警报的静默提供了详细信息。该页面包括每个静默的状态以及静默结束时间的摘要。

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

  • State 过滤器：

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

在 Administrator 视角中，Alerting UI 中的 Alerts Rules 页面针对与 OpenShift Container Platform 默认项目和用户定义的项目相关的警报规则提供了详细信息。该页面包括每个警报规则的状态、严重性和来源摘要。

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

  • 警报状态 过滤器：

    • Firing。警报正在触发，因为满足警报条件，且可选的 for 持续时间已过。当条件保持 true 时，警报将继续触发。
    • Pending。该警报处于活跃状态，但正在等待警报规则中指定的持续时间，然后再触发警报。
    • Silenced。现在，警报在定义的时间段内处于静默状态。静默会根据您定义的一组标签选择器临时将警报静音。对于与所有列出的值或正则表达式匹配的警报，不会发送通知。
    • Not Firing。警报未触发。

  • Severity 过滤器：

    • Critical。警报规则中定义的条件可能会产生重大影响。如果满足这些条件，需要立即关注。与该规则相关的警报通常会传给个人或关键响应团队。
    • Warning。警报规则中定义的条件可能需要注意，以防止问题的发生。与该规则相关的警报通常会路由到一个问题单系统进行非即时的审阅。
    • Info。警报规则仅提供信息警报。
    • None。该警报规则没有定义的严重性。
    • 您还可以针对与用户定义的项目相关的警报规则创建自定义严重性定义。

  • Source 过滤器：

    • Platform。平台级别的警报规则仅与 OpenShift Container Platform 默认项目相关。这些项目提供 OpenShift Container Platform 核心功能。
    • User。用户定义的工作负载警报规则与用户定义的项目相关。这些警报规则是用户创建的，并可自定义。用户定义的工作负载监控可在安装后启用，以便您观察自己的工作负载。
1.3.5.7.4. 在 Developer 视角中搜索和过滤警报、静默和警报规则

在 Developer 视角中，Alerting UI 中的 Alerts 页面提供了与所选项目相关的警报和静默的组合视图。对于每个显示的警报，都提供了相关警报规则的链接。

在该视图中，您可以按警报状态和严重性进行过滤。默认情况下，如果您有访问所选项目的权限，则会显示项目中的所有警报。这些过滤器与针对 Administrator 视角描述的过滤器相同。

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

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

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

用户为用户定义的项目定义了警报路由后，用户定义的警报通知会路由如下：

  • 如果使用默认平台 Alertmanager 实例，到 openshift-monitoring 命名空间中的 alertmanager-main pod。
  • 如果您为用户定义的项目启用了一个单独的 Alertmanager 实例，到 openshift-user-workload-monitoring 命名空间中的 alertmanager-user-workload Pod。
注意

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

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

其他资源

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

在 OpenShift Container Platform 4.16 中，可在 Alerting UI 中查看触发警报。默认不会将警报配置为发送到任何通知系统。您可以将 OpenShift Container Platform 配置为将警报发送到以下类型的接收器：

  • PagerDuty
  • Webhook
  • 电子邮件
  • Slack
  • Microsoft Teams

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

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

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

其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.